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SECTION  I 
INTRODUCTION 


The  digital  Quided  Weapon  X®chnology  orogram  was  initiated  with 
the  general  intent  of  determining  the  role  of  digital  processing  tech¬ 
niques  in  guided  weapons.  Recognizing  that  too  broad  a  scooe  can  be 
self-defeating  for  this  kind  of  program,  the  Air  Force  set  two  soecific 
goals  to  be  accomplished.  The  first  was  a  near  term  application  of 
digital  processing  to  an  existing  weapon  family.  Specifically,  a  digital 
autopilot  for  tie  GBU-15  weapon  was  to  be  designed  and  evaluated. 

The  evaluation  required  fabrication  of  a  brassboard  digital  processor 
for  the  autopilot  and  verification  of  its  performance  with  a  hybrid  simu- 
ation.  This  part  of  the  program  was  completed  in  1975.  Based  on  the 
results  of  that  effort,  a  separate  program  was  initiated  to  bring  the 
GBU-15  digital  autopilot  into  engineering  development.  The  Program¬ 
mable  Digital  Autopilot  (PDAP)  work  is  reported  in  a  separate  volume. 

The  second  goal  was  to  determine  how  digital  processing  techniques 
could  be  used  to  assist  in  integrating  the  components  of  an  advanced 
modular  weapon  system.  Earlier  studies  sponsored  by  the  Air  Force 
had  investigated  the  characterisitics  of  a  modular  weapon.  The  results 
of  one  of  these,  as  expressed  in  AFATL- TR-72-202,  were  used  as  a  ^ 
starting  point  to  define  the  weapon  system  To  be  studied  in  the  DGWT 
program.  Specifically,  the  program  was  to  accomplish  the  following: 

1,  Determine  what  functions  could  be  done  digitally  in  the  weapon 
system. 

2,  Determine  what  the  digital  processing  system  should  do  to 
assist  in  integrating  the  weapon  components. 

3.  Determine  what  other  functions  should  be  done  in  the  digital 
processor, 

4,  Define  the  interface  of  the  digital  processing  subsystem  within 
the  weapon  system, 

5,  Determine  the  requirements  of  the  digital  processing  system. 

6.  Produce  a  preliminary  design  of  the  digital  processing  system. 

7.  Build  two  breadboard  processing  systems. 

8.  Evaluate  the  breadboard  systems  in  hybrid  simulations  and 
other  tests. 

The  present  volume  reports  on  the  first  six  of  the  tasks  listed 
above.  The  description  of  the  breadboard  hardware  and  the  results 
of  system  evaluation  are  reported  in  separate  volumes.  This  volume 
is  organized  so  as  to  present  a  step-by-step  accounting  of  the  design 
process  which  ended  with  the  preliminary  design  of  the  digital  pro¬ 
cessing  system  presented  in  Section  VII.  The  performance  require¬ 
ments  for  the  processing  system  are  summarized  in  Section  VII  and 
are  presented  in  greater  detail  in  a  specification  which  is  published 
as  a  separate  document. 


The  major  findings  of  the  study  are  summarized  below  along  with 
a  brief  description  of  the  contents  of  other  sections  in  this  book. 

Modularity  requirements  of  the  weapon  system  led  to  the  choice  of 
uf  a  multipleyed  digital  bus  as  tlu.  prim*  ccmmunication  channel  in  the 
weapon.  The  weapon  bus  presents  a  common  interface  to  all  subsys¬ 
tems  and  provides  a  common  functional  interface  between  weapon  sec¬ 
tions.  The  combination  of  a  digital  processor  and  the  weapon  bus  form 
the  integration  subsystem  of  the  weapon.  The  functions  which  are  per¬ 
formed  in  the  digital  processor  to  accomplish  integration  are  called 
the  CORE  functions.  These  CORE  functions  are  system  management, 
flight  control,  and  the  strapdown  inertial  navigation  function.  System 
management  includes  weapon  system  identification,  communication 
control,  and  self-test.  It  provides  the  real  time  control  of  the  weapon 
system  processor.  The  strapdown  inertial  reference  function  includes 
the  data  filtering  and  position  update  tasks  which  interface  midcourse 
aviiS^rs  with  ti.v.  iiitrtlal  navigatt^r*  Inoeii-m. 

Other  weapon  functions  can  be  performed  in  the  digital  processor. 
These  additional  functions  are  not  typically  common  to  most  weapon 
configurations  as  are  the  CORE  functions.  The  criteria  for  adding 
configuration  dependent  functions  to  the  digital  processor  repertoire 
are; 

•  No  increase  in  digital  processing  system  requirements, 

•  There  should  be  an  economic  benefit. 

•  Subsystem  interfaces  are  simplified  or  at  least  not 
complicated. 

Some  functions  which  are  good  subjects  for  digital  implementation  do 
not  sr.tisfy  the  above  criteria.  An  example  is  the  video  tracker  in  the 
electro-optical  (E-Ol  seeker.  Performing  this  function  in  the  integ¬ 
ration  subsystem  does  increase  bus  transmission  requirements  and 
processor  throughput  requirements.  Moreover,  it  complicates  the 
subsystem  interface.  While  such  functions  should  be  performed  digi¬ 
tally,  it  should  be  in  a  separate  processor. 

The  throughput  requirement  on  the  digital  processing  system  is 
determined  by  time  critical  functions  in  the  flight  control  subsystems. 
Propagation  delay  restrictions  in  processing  inertial  sensor  data  for 
the  hight  control  stabilization  function  set  both  bus  tramsmission  rate 
and  procesor  throughput  capability. 

The  digital  processor  itself  could  be  implemented  either  as  a 
«ing,li  proftnior  ur  a  dlatributed  processor*  Tradeoff  studies  showed 
no  system  or  economic  advantage  to  using  a  distributed  processing 
system.  In  fact,  for  the  CORE  functions,  using  a  distributed  pro¬ 
cessing  system  leads  to  higher  costs  than  using  a  single  processor. 

The  software  structure  recommended  for  the  digital  processing 
uysttm  a  Stiniplr  exjfcutive  which  pruvIduB  tht  Interface 

between  the  hardware  system  and  the  software  system,  and  also 
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provides  the  interface  betwet'n  functional  software'  modules.  This 
structure  is  cemsistent  w'ith  weapon  modularity  requirements.  Soft¬ 
ware  modules  can  be  adde'd  to  or  deleted  from  the  system  with  little 
or  no  effect  on  other  modules. 

The  weapon  system  used  as  the*  basis  for  the  study  is  described 
in  Section  II. 

Three  weafjon  configurations  are  selected  for  detail  study.  The 
configurations  Acre  chosen  to  cover  a  range  of  complexities  so  that  the 
effect  of  \'arying  requiremt'nts  on  the  digital  processor  could  be' 
assessed. 

The  procedures  used  to  carry  out  the  tradeoff  studies  and  arrive 
at  a  digital  system  design  are  discussed  in  Section  III.  Design  method¬ 
ology  and  tradeoff  criteria  are  also  described  here. 

Weapon  subsystems  is  the  subject  of  Section  IV.  A  selection  of 
major  subsystems  is  chosen,  and  the  digital  processing  requirements 
for  each  are  analyzed.  The  viewpoint  here  is  to  determine  what  func¬ 
tions  in  the  subsystem  can  be  done  digitally  and  what  is  the  effect  on 
processor  requirements  by  choosing  different  interfaces.  The  digital 
processor  requirements  for  each  subsystem  are  determined  as  a  func¬ 
tion  of  the  interface. 

The  design  process  is  carried  to  the  system  level  in  Section  I 
where  the  requirements  for  each  of  the  three  chosen  weapon  configura¬ 
tions  are  examined,  The  viewpoint  of  this  section  is  to  determine  the 
requirements  of  a  digital  processor  that  is  optimized  for  a  single 
weapon  configuration.  Subsystem  interfaces  are  selected  and,  for 
each  configuration,  the  requirements  corresponding  to  those  inter¬ 
faces  are  selected,  it  is  made  clear  that  optimizing  for  particular 
configurations  does  not  lead  to  a  common  set  of  requirements  for  the 
digital  processor. 

The  role  of  the  digital  processor  in  integrating  the  components  of 
a  fixed-design  weapon  is  discussed. 

The  question  of  integration  in  a  modular  weapon  is  addressed  in 
Section  VI.  The  method  of  integration  in  a  fixed-design  weapon  must 
be  extended  to  satisfy  modularity  requirements.  The  requirements 
lead  to  the  selection  of  a  multiplexed  digital  bus  and  a  digital  pro¬ 
cessor  to  form  the  integration  subsystem.  Weapon  functions  which 
are  closely  related  to  the  integration  process  should  be  performed 
in  the  digital  processor.  These  CORE  functions  are  selected. 

The  digital  processing  system  design  is  described  in  Section  VII. 
Weapon  bus  tradeoffs  lead  to  the  selection  the  bus  configuration. 

A  tradeoff  of  processor  configurations  leads  to  the  selection  of  a 
single  processor  to  perform  the  CORE  functions.  The  software  struc¬ 
ture  is  deSCiibed  and  perfOinianee  i  equlx  eTiients  on  the  digital  pro¬ 
cessor  system  are  presented.  The  section  closes  with  a  brief  dis¬ 
cussion  of  other  functions,  other  than  CORE  functions,  which  might 
be  performed  in  the  digital  processor. 
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Section  VIII  contains  the  results  of  a  study  conducted  to  determine 
appropriate  technology  for  implementing  the  digital  processor. 

The  cost  analysis  reported  in  Section  IX  analyzed  cost  differences 
in  the  digital  processing  system  which  resulted  from  different  ways  of 
implementing  the  processor.  The  tradeoff  contains  a  comparison  of 
single  processor  systems  and  distributed  processor  systems. 


SECTION  II 

WEAPON  SYSTEM  DEFINITION 


Different  tactical  air-to-surface  guided  weapons  share  many 
common  functions.  Figure  1  illustrates  a  generic  guided  weapon  con¬ 
figuration  broken  into  its  basic  functional  ^.arta,  Tkc  conimunaiily  uf 
these  parts  can  be  clearly  seen  in  existing  weapons.  Each  weapon,  for 
example,  requires  some  form  of  guidance  to  indicate  the  direction  of 
the  intended  target,  a  control  module  to  produce  maneuvers  to  reach 
the  target,  and  a  warhead  module  to  destroy  the  target  upon  impact. 

In  recent  years,  it  has  been  widely  recognized  that  there  are  sig¬ 
nificant  benefits  to  approach? ng  tactical  weapon  design  from  the  view¬ 
point  of  modularity.  The  chief  benefit  is  reduced  cost,  both  in  weapon 
system  development  and  production.  This  cost  benefit  comes  princi¬ 
pally  through  commonality  of  design.  For  example,  although  it  may 
be  attractive  to  consider  different  types  of  weapon  guidance  under 
particular  conditions  (e.  g.  ,  maximum  accuracy  E-O  guided  weapons 
in  good  weather  and  lower  accuracy  weapon  guidance  such  as  DME 
for  area  targets)  the  same  airframe  and  control  modules  may  be 
entirely  adequate  for  either  condition.  Therefore,  development  of  a 
weapon  design  which  utilizes  different  guidance  modules  for  the  same 
airframe  would  be  cost  effective.  Although  some  small  additional 
development  cost  would  be  incurred  to  ensure  interchangeability  of 
the  guidance  units,  development  cost  associated  with  two  different 
airframes  and  control  modules  would  be  avoided.  In  production,  the 
costs  can  be  reduced  since  the  fabrication  of  any  number  of  a  single 
design  is  substantially  less  costly  than  that  of  one-half  the  number  of 
eacti  of  two  separate  designs. 

While  the  benefits  of  modularity  are  evident  from  the  preceding 
discussion,  there  have  been  a  number  of  stumbling  blocks  in  the  way 
of  successfully  achieving  it.  One  such  stumbling  block  is  providing  the 
functional  adaptivity  required  to  accommodate  the  different  modules. 
For  example,  a  laser  terminal  seeker  has  somewhat  different  inter¬ 
face  requirements  than  an  E-O  terminal  seeker.  The  output  steering 
signals  have  different  filtering  requirements.  Different  warheads 
require  different  guidance  laws  to  give  the  optimum  trajectory.  Over 
the  entire  subsystem  spectrum,  there  are  many  of  these  differences 
which  require  some  medium  to  provide  the  proper  adjustment.  The 
adjustnient  can  be  made  by  adapter  modules,  either  peruiuneiitly 
placed  in  the  subsystem  or  used  in  an  ad  hoc  fashion.  Either  method 
has  disadvantages.  One  of  the  prime  objectives  of  this  study  was  to 
deteriiiine  how  a  digital  processing  systcjii  cau  help  in  obtaining  this 
functional  adaptivity. 

As  a  first  step  in  analyzing  the  problem,  a  basic  weapon  system 
was  defined.  The  elements  of  this  weapon  system  are  illustrated  in 
Figure  2. 


The  figure  illustrates  the  candidate  tactical  weapon  subsystem 
considered  in  establishing  total  weapon  processing  requirements. 

These  are  grouped  in  terms  of  primary  functions  such  as  midcourse 
and  terminal  guidance  and  arranged  in  an  approximate  time  line  of 
when  they  occur  during  missile  flight.  The  weapon  configuration  is 
simply  a  combination  of  one  of  each  of  the  functional  elements.  From 
these  candidate  subsystems,  three  weapon  configurations  have  been 
sil»ct^c!  for  de  tail rd  analysis.  Th*  configurations  have  bt^n  specifi¬ 
cally  chosen  to  represent  a  range  from  low  to  high  processing  com¬ 
plexity  to  determine  how  weapon  complexity  affects  digital  processor 
requirements . 

The  most  complex  of  the  three  selected  weapon  configurations  is 
shown  in  Figure  3.  The  vehicle  is  a  low  volume  ramiet  tvpe  of  cruise 
missile,  such  as  is  being  developed  at  the  Naval  Weapons  Center,  China 
Lake,  California,  having  a  range  on  the  order  of  a  few  hundred  miles. 

A  fuel  management  processing  function  is  assumed  for  the  vehicle's 
engine. 

Guidance  for  the  vehicle  is  provided  during  both  midcourse  and 
terminal  phases  of  flight  by  navigation  in  a  guidance  computer,  using 
the  outputs  of  an  inertial  measurement  unit  (IMU)  updated  periodically 
with  pciBltiuji  Iron.  &  radiorm-trif  arta  correlation  senBi.r.  other 

functions  assumed  are  built -in-test  (BIT),  a  digital  fuze,  and  the 
flight  control  function. 

The  moderate  complexity  configuration  chosen  (Figure  4)  utilizes 
a  long  range  glide  weapon  aerodynamic  configuration,  represented  by 
the  GBU-15(V)  with  a  planar  wing  module.  This  weapon  is  controlled 
during  midcourse  flight  by  navigation  based  on  a  combination  of 
inertial  sensor  information  (illustrated  as  an  IMU  module)  and  LORAN 
receiver.  After  navigation  to  the  target  area,  the  target  would  then 
be  acquired  by  an  electro-optical  terminal  seeker  through  use  of  a 
dt>ta  llni'. 

Additional  functions  of  flight  control,  a  digital  fuze,  and  built-in¬ 
test  are  also  included  in  this  configuration. 

The  third  configuration,  selected  to  represent  a  lower  level  of 
complexity  than  the  previous  configurations,  employs  the  GBU-  15(V) 
with  the  cruciform  wing  module  as  the  vehicle.  This  weapon,  having 
a  maximum  range  far  beyond  the  lock-on  capability  of  the  selected 
Imaging  Infrared  Terminal  Seeker,  utilizes  DME  for  midcourse 
guidance  and  a  data  link  to  allow  target  acquisition  at  long  range.  The 
only  additional  function  assumed  is  the  flight  control  function.  (See 
Figure  5.  ) 

For  each  of  these  three  weapon  configurations,  the  processing 
requirements  for  the  subsystem  will  be  determined  for  various  inter¬ 
faces  within  the  subsystems.  Then  a  point  design  for  each  configura¬ 
tion  will  be  analyzed  to  determine  the  processing  requirements  for  a 
fixed-design  weapon.  These  point  designs  will  form  the  basis  for 
examining  modularity  requirements  for  the  digital  processor. 
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SECTION  III 

DIGITAL  SYSTEM  DESIGN  PROCEDURE 


The  design  of  a  digital  processing  system  to  be  a  component  of 
all  possible  configurations  of  a  modular  weapon  system  is  a  complex 
process.  The  most  difficult  problem  is  the  determination  of  the  role 
of  the  digital  processor  in  each  weapon  configuration  which  will  mini¬ 
mize  the  overall  system  cost.  The  problem  is  aggravated  by  probable 
addition  of  new  subsystems  (currently  undefined)  to  the  weapon  system 
in  the  future  resulting  in  a  proliferation  of  weapon  configurations.  To 
maintain  perspective  on  a  problem  which  is  potentially  unbounded,  the 
following  procedure  was  adopted. 

The  system  design  process  shown  in  Figure  6  was  applied  to  each 
of  the  three  weapon  configurations  determined  in  the  previous  section. 
Digital  processor  requirements  were  determined  for  various  interface 
definitions  within  the  subsystems  of  these  configurations.  These 
interface  definitions  ranged  from  treating  the  subsystem  as  a  unit 
(minimum  digital  system  requirement)  to  performing  digitally  all 
functions  which  are  technically  feasible.  The  results  of  these  studies 
for  the  three  configurations  were  correlated  to  determine  a  range  of 
digital  processing  requirements  within  which  to  perform  system 
optimization.  The  primary  emphasis  in  the  optimization  process  was 
placed  on  the  partitioning  of  the  system  functions  between  the  digital 
processor  and  dedicated  processing  elements.  Various  processor 
designs  were  performed  to  encompass  the  rfinge  of  processing 
requirements  as  an  integral  part  of  this  study. 

To  ensure  that  the  results  of  this  process  were  applicable  to  the 
total  weapon  system,  other  subsystems  beyond  those  involved  in  the 
three  configurations  were  studied  in  determining  final  digital  proces¬ 
sor  requirements.  These  subsystems  were  exi.mined  in  sufficient 
detail  to  validate  the  conclusions  made  on  the  basis  of  the  three  con¬ 
figurations.  The  remainder  of  this  section  is  concerned  with  the 
detailed  methodology  used  in  the  design  process. 

3.1  SYSTEM  DESIGN  PROCESS 


The  system  design  process  shown  in  Figure  6  delineates  an 
orderly  procedure  which  was  followed  in  the  design  of  the  digital 
processor.  The  primary  inputs  to  the  process  are  the  system  level 
requirements  which  include  not  only  performance,  but  also  assembly 
and  maintenance  procedures  and  system  operating  philosophy.  The 
system  level  requirements  can  be  used  to  derive  a  set  of  functional 
requirements  at  the  weapon  configuration  level,  at  the  component 
subsystem  level,  and  at  the  subsystem  function  level.  The  functional 
requirements  are  the  basis  for  the  partitioning  study  in  which  all 
functions  of  each  weapon  configuration  are  placed  in  one  of  four 
categories:  analog,  interface,  special  purpose  digital,  and  general 
purpose  digital.  The  final  determination  of  the  system  partitioning 
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Figure  6,  System  Design  Process 

is  made  on  the  basis  of  the  cost  effectiveness  of  the  resulting  design. 
This  system  level  optimization  process  must  consider  not  only  the 
effect  of  the  partitioning  on  digital  processor  cost  but  also  the  effect 
on  the  costs  associated  with  the  other  weapon  subsystems.  A  detailed 
evaluation  of  subsystem  costs  for  various  functional  partitionings  was 
not  performed  in  this  study,  but  current  implementation  trends  in 
similar  subsystems  were  used  to  establish  viable  functional  parti¬ 
tioning  for  this  weapon  system. 

3.2  SUBSYSTEM  CHARACTERIZATION 

As  a  first  step  in  the  partitioning  process,  e'ch  subsystem  was 
characterized  as  shown  in  Figure  7.  The  characteristics  of  interest 
are  the  data  and  control  requirements  (interface),  the  operations  and 
processes  performed  by  the  subsystem,  and  the  performance 
required  of  the  subsystem  as  a  component  part  of  the  weapon.  The 
interface  and  performance  requirements  must  be  defined  not  only  at 
the  subsystem  level  but  also  for  the  internal  functions  of  the  sub¬ 
system.  Partitioning  of  subsystem  level  performance  requirements 
among  the  component  functions  of  the  subsystem  is  not  inique  but  is 
generally  implementation  dependent.  The  key  to  the  most  cost- 
effective  subsystem  implementation  is  the  use  of  the  minimum  cost 
technology  which  meets  the  requirements  for  each  of  the  functions. 
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Mat^y  of  the  cotiipoiiciit  suLsysttnis  either  are  in  prudaelion  or 
are  in  some  stage  of  development.  It  was  not  the  goal  of  this  study 
to  redesign  these  subsystems  in  digital  technology.  The  reason  for 
eXdiiixliiXi  Llit;  mlt:  rildi  of  tllti&e  SuL &y  Slcilib  Wd.b  to  b1.clljl.ibl:i 

requirements  for  typical  functions  which  might  be  incorporated  in  the 
digital  processor  for  advanced  subsystems  of  the  same  type. 

The  selection  of  candidate  digital  processing  functions  from  each 
subsystem  was  made  on  the  basis  of  the  operations  and  processes 
involved  in  the  functions,  the  accuracy  r.  quir»  mvnts,  ar.d  the  band¬ 


width  of  the  interface  signals.  These  functional  characteristics  were 
used  in  conjunction  with  previously  determined  digital  processing 
reiquireiitents  fjr  ftH.clkiift  with  similar  characicf latics  to  ptr£u-«i. 
a  gross  partitioning  between  digital  and  analog  implementation. 


Figure  7,  Subsystem  Characterization 


3.3  DIGITAL  FUNCTION  PARTITIONING 

Digital  processing  requirements  for  each  candidate  subsystem 
function  were  determined  by  the  procedure  shown  in  Figure  8.  The 
first  step  is  the  selection  of  an  appropriate  processing  algorithm  for 
the  function.  Since  an  algorithm  is  a  method  of  performing  the 
desired  function  within  the  functional  requirements,  the  term  may 
be  applied  to  either  analog  or  digital  implementations.  Every 
algorithm  is  an  approximate  solution  to  the  ideal  function,  and  the 
functional  requirements  define  the  allowable  deviations  from  the 
ideal.  The  optimum  algorithm  considers  the  strong  and  weak  points 
of  the  implementation  technology  to  minimize  implementation  com¬ 
plexity.  Consequently,  the  optimum  algorithm  is  usually  different 
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Figure  8,  Digital  Function  Partitioning 


for  analog  and  digital  implementations.  Therefore,  the  procedure 
involved  the  identification  of  the  ideal  solution,  when  possible,  and 
definition  of  digital  processing  algorithms  for  evaluation.  For  cases 
in  which  the  ideal  solution  could  not  be  determined,  a  digital  approxi¬ 
mation  to  the  analog  implementation  was  made. 


The  digital  processing  algorithms  were  evaluated  from  a  perfor¬ 
mance  viewpoint  and  processing  requirements  were  determined.  The 
generation  of  algorithms  with  improved  performance  was  not  a  goal, 
but  potential  performance  improvements  were  identified  as  a  weight¬ 
ing  factor  for  growth  provisions.  Digital  processing  requirements 
for  each  algorithm  were  evaluated  by  performing  sample  programming 
using  appropriate  instruction  types.  The  instruction  types  were 
selected  or  the  basis  of  the  operations  implied  by  the  algorithms  as 
shown  in  Table  1.  The  results  of  this  evaluation  were  memory  size 
(data  and  program),  a  sample  instruction  set,  and  instruction  through¬ 
put  requirements  for  the  digital  processor.  A  preliminary  examina¬ 
tion  of  these  results  was  used  to  partition  the  digital  functions  into 


TABLE  1.  OPERATIONS  AND  INSTRUCTION  TYPES 


OPERATIONS 

INSTRUCTION  TYPE 

ADDRESSING  MODES 

EXECUTIVE  AND  CONTROL 

TRANSFER  OF  CONTROL 

DATA  DISTRIBUTION 

•  UNCONDITIONAL 

•  INDIRECT 

INTERRUPT  SERVICING 

•  CONDITIONAL 

•  DIRECT 

FILTERING 

DATA  MANIPULATION 

INTEGRATION 

•  TRANSFER 

•  REGISTER 

SCALING 

•  ARITHMETIC 

•  IMMEDIATE 

TRANSCENDENTAL  FUNCTIONS 

•  LOGIC 

•  DIRECT 

LIMITING 

•  INPUT/OUTPUT 

•  INDEXED 

DECISION  MAKING 

•  TEST 

ARRAY  DATA  PROCESSING 

MACHINE  CONTROL 

•  INTERRUPT  CONTROL 

three  categories:  general  purpose  (software  control),  special  pur¬ 
pose,  and  interface  functions.  A  more  definitive  partitioning  was 
made  by  determining  the  implications  of  various  functional  partition¬ 
ing  on  digital  processor  design. 

The  processing  requirements  for  the  individual  subsystem  func¬ 
tions  were  now  combined  to  determine  total  processing  requirements 
for  various  weapon  configurations.  As  a  first  step  in  this  process, 
the  functions  were  divided  into  two  categories:  weapon  configuration 
common  and  configuration  dependent.  The  functions  were  also 
screened  for  completeness,  i.e,,  some  weapon  configuration  func¬ 
tions  are  not  attributable  to  any  specific  weapon  subsystem  but 
logically  should  be  performed  by  the  digital  processor.  The  result 
of  these  analyses  waf^  a  range  of  processor  requirements  for  use  in 
processor  design  tradeoffs. 

3.4  DIGITAL  PROCESSOR  DESIGN 

The  digital  processor  design  process  is  shown  in  Figure  9. 
Various  digital  processor  architectures  were  examined  to  determine 
their  ability  to  meet  the  range  of  processing  requirements.  This 
investigation  included  both  digital  processing  system  architectures 
(central  versus  distributed)  and  processor  architectures  (single  CPU 
versus  multi-processor).  The  applicable  architectures  and  available 
digital  component  technology  (in  various  semi-conductor  families) 
were  prime  inputs  to  the  processor  implementation  study.  The 
system  level  requirements  on  weapon  assembly  and  operating  proce¬ 
dures  were  also  used  in  determining  viable  processor  implementa¬ 
tions.  Those  processor  implementations  which  were  capable  of 
performing  over  a  relatively  wide  range  of  requirements  were 
evaluated  to  determine  cost  versus  performance  factors  which  were 
used  in  system  optimization  studies. 


PROCESSOR  REQUIREMENTS 


Figure  9.  Digital  Processor  Design 


The  end  result  of  the  system  design  process  is  a  specification 
of  digital  processing  system  requirements.  These  requirements  are 
determined  by  applying  a  growth  factor  to  the  minimum  capability 
required  for  weapon  system  integration  and  configuration  common 
functions.  This  growth  factor  is  necessary  to  accommodate  system 
level  growth  in  the  integration  and  common  functions  since  the  system 
is  not  totally  defined.  To  some  extent,  the  processor  growth  capa¬ 
bility  may  be  utilized  to  perform  some  configuration  dependent 
functions  within  the  existing  system  definition.  However,  as  a 
ground  rule,  a  subsystem  function  should  not  be  performed  by  the 
digital  processor  unless  sufficient  capability  is  available  to  perform 
the  function  for  all  weapon  configurations. 

This  section  has  provided  an  overview  of  the  analysis  procedures 
and  tradeoff  criteria  used  in  the  design  of  the  digital  processor  sys¬ 
tem.  Section  IV  summarizes  the  analysis  of  subsystem  requirements, 
and  Section  V  summarizes  the  digital  processor  system  tradeoffs. 
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SECTION  IV 

SUBSYSTEM  DESCRIPTIONS  AND  REQUIREMENTS 


The  component  subsystems  of  the  weapon  system  have  been 
examined  to  determine  the  applicability  of  digital  processing  to  the  func¬ 
tions  of  each  subsystem.  The  subsystems  have  been  collected  accord¬ 
ing  to  their  role  in  the  weapon  system,  e.g.  ,  midcourse  guidance.  The 
characteristics  of  each  subsystem  have  been  analyzed,  and  candidate 
digital  processing  functions  have  been  selected  for  requirements  analy¬ 
sis.  The  effects  of  different  interface  definitions  and  processing  algo¬ 
rithms  an  Wjgyglem  digital  requif fcU.tnls  are  presented  for 

each  subsystem.  Detailed  functional  requirements  were  not  available 
for  some  subsystems  of  this  weapon  system.  For  these  cases,  require¬ 
ments  were  generated  using  similar  subsystems  which  are  identified  in 
the  corresponding  section. 


The  digital  processing  requirements  for  the  functions  of  each  sub¬ 
system  include  memory  (program  and  operand),  instruction  throughput, 
and  input /output  data  rate.  The  iteration  rate  of  each  algorithm  is 
indicated  where  applicable.  Instruction  throughput  requirements  are 
shown  for  both  short  and  long  instruction  types  depending  on  instruction 
feXeetttic-n  tinvt.  Lung  instructicns  consist  of  multiplication  and  division 
operations,  and  all  other  instruction  types  are  in  the  short  category. 

4.  1  MIDCOURSE  GUIDANCE  SUBSYSTEMS 

All  midcourse  guidance  subsystems  pertinent  to  this  weapon  sys¬ 
tem  can  be  characterized  as  shown  in  Figure  10,  Initial  conditions  on 
target  position  and  weapon  position  and  velocity  are  supplied  by  the 
avionics  prior  to  weapon  launch.  The  midcourse  guidance  subsystem 
updates  weapon  position  and  velocity  data  during  flight  based  on  environ¬ 
mental  measurements.  These  measurements  may  be  only  the  weapon 
environment  (attitude,  accelerations)  or  some  combination  of  weapon 
and  external  environments.  The  guidance  law  operates  on  weapon  posi¬ 
tion  and  velocity  relative  to  the  target  position  (or  an  intermediate  aim 
point)  to  control  the  weapon  trajectory.  Although  all  of  the  midcourse 
guidance  subsystems  provide  an  essentially  equivalent  system  function, 
there  is  considerable  variation  in  their  internal  functions,  as  noted, 
which  also  results  in  variations  in  format,  type,  and  quantity  of  initial 
condition  data  which  must  be  supplied.  Some  of  the  midcourse  guidance 
subsystems  are  also  capable  of  providing  terminal  guidance  information, 
and  the  variation  in  funrllonal  i6  «h<jwr.,  where  appHcAblt. 


4.  1.  1  Strapdown  Inertial  Reference  Subsystem 


A  functional  block  diagram  of  a  strapdown  inertial  reference  sub¬ 
system  is  shown  in  Figure  I'l.  Initial  conditions  on  weapon  attitude, 
velocity,  and  position  in  an  inertial  coordinate  frame  are  supplied  by 
the  avionics  prior  to  weapon  launch.  After  initialization,  the  weapon 
attitude  in  the  inertial  frame  is  updated  on  the  basis  of  three-axis 
angular  rate  (nr,  a  1 1,  i-nuiivrly,  ar.gW  from  l-cvdy-fixtd 

inertial  sensors.  Weapon  velocity  and  position  in  the  inertial  frame 
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Figure  10.  Midcourse  Gmdance  Characterizati^ 


I  AVIONICS  I 

I _ I 

INPUTS:  INITIAL  CONDITIONS  -  ATTITUDE  (3).  VELOCITY  (3)  POSITION  (3) 
RATES  (3) 

ACCELERATIONS  (3) 

OUTPUTS:  VELOCITY  (3),  POSITION  (3) 

Figure  11.  Strapdown  Inertial  Reference  Block  Diagram 


are  computed  by  transforming  sensed  acceleration  (or  velocity  increment) 
data  from  three-axis  body-fixed  sensors  into  the  inertial  frame  and  per- 
foi-ming  thi  Appfotjriat*  I'-  UgrB lions  Tht  oir.didate  digital  processing 
functions  for  this  subsystem  are  the  attitude,  velocity,  and  position 
computation  elements. 

As  a  first  step  in  determining  the  digital  processing  requirements 
for  these  functions,  the  subsystem  performance  requirements  mvist  be 
determined.  The  following  assumptions  were  made  on  subsystem 
requirements: 

(1)  The  strapduwn  inertial  reference  sabs/atem  is  not  required 
to  operate  autonomously  during  the  midcour'e  phase  as  a  source  of 
weapon  inertial  data  but  will  always  receive  inflight  corrections  from 
another  weapon  subsystem.  Formatting  of  correction  data  will  be  per¬ 
formed  by  the  software. 

(2)  Autonomous  subsystem  performance  requirements  are  most 
stringent  when  operating  in  conjunction  with  the  radiometric  area  cor¬ 
relation  (RAC)  subsystem. 

(3)  The  digital  processing  algorithms  must  provide  accuracy  com¬ 
patible  with  thi'  hsglu^Bt  qaTlity  iehsore  sMicip^ted  tTictical 

missile  usage.  Software  compensation  of  low  quality  instrument  errors 
is  required. 

(4)  Mechanical  alignment  of  the  sensors  is  not  compatible  with 
subsystem  accuracy  requirements,  and  the  misalignment  must  be  cor¬ 
rected  within  the  digital  processor. 

(5)  Inertial  reference  attitude,  velocity,  and  position  data  will  be 
combined  with  target  and  aimpoint  data  using  a  generalized  guidance 
law  for  appropriate  weapon  trajectory  control. 

(6)  An  altimeter  is  required  for  vertical  channel  stabilization  if 
the  coli.pnik'ij  subsystei.i  does  not  provide  altitude  collections. 

Using  these  assumptions,  the  digital  processing  functions  associ¬ 
ated  with  the  strapdown  inertial  reference  are  defined  in  Figure  12. 

The  conversion  of  angle  rates  and  accelerations  to  incremental  angles 
and  velocities  may  be  performed  either  in  the  digital  processor  or  the 
inertial  sensors  depending  on  the  sensor  output  data  format.  The  sen¬ 
sor  compensation  software  corrects  the  sensor  data  using  a  combina¬ 
tion  of  pre- stored  data  and  data  derived  by  the  alignment  function. 

The  attitude  computation  operates  on  the  incremental  angle  data 
using  a  third  order  quaternion  algorithm  similar  to  the  algorithm  used 
in  the  ATIGS,  a  high  quality  inertial  subsystem  undergoing  development 
by  the  Navy.  The  quaternions  are  used  to  generate  a  transformation 
rnatrix  from  body  coordinates  (sensor  frame)  to  a  locally  level  naviga¬ 
tion  coordinate  frame  with  weapon  position  determined  in  latitude  and 
longitude.  The  incremental  velocity  data  is  transformed  to  the  naviga- 
tkji.  frame  and  SuiuUied  to  determine  velocity.  The  velocity  data  is 
integrated  to  determine  weapon  position.  Corrections  are  made  for 
gravity  and  coriolis  effects. 
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The  alignment  filter  uses  velocity  and  position  data  from  the 
avionics  and  the  inertial  reference  to  estimate  attitude  misalignment 
angles  and  gyro  biases.  A  seven  state  Kalman  filter  is  used  for  this 
function  which  is  performed  prior  to  weapon  launch.  To  perform 
in-flight  corrections,  the  data  from  the  companion  subsystem  is  for¬ 
matted  to  serve  as  reference  input  data  (or  measured  error  data, 
depending  on  subsystem)  for  the  Kalman  filter.  Corrections  are  made 
to  the  inertial  reference  data  (attitude,  velocity,  position)  on  the  basis 
of  the  bandwidth  of  data  supplied  by  the  companion  subsystem.  For 
example,  the  RAC  subsystem  data  will  be  used  to  correct  only  position, 
while  LORAN  or  GPS  data  has  sufficient  bandwidth  to  allow  estimation 
of  errors  in  all  parameters. 

The  navigation  function  generates  steering  commands  for  the  flight 
control  based  on  line  of  sight  (LOS)  angle  and  LOS  angle  rate  data 
derived  from  weapon  velocity  and  position  relative  to  a  desired  aim- 
point  and  approach  angle  for  appropriate  operation  of  the  companion 
subsystem.  These  parameters  are  discussed  in  more  detail  in  the 
descriptions  of  the  other  midcourse  subsystems. 

The  digital  processing  requirements  for  the  strapdown  inertial 
reference  functions  are  shown  in  Table  2.  These  data  assume  the 
highest  expected  iteration  rate  for  the  configuration  dependent  functions 


TABLE  2.  PROCESSING  REQUIREMENTS  -  STRAPDOWN 
INERTIAL  REFERENCE 


FUNCTION 


PROGRAM  OPERAND 

SIZE  MEMORY 


IMU  COMPENSATION,  800 

attitude,  velocity, 

POSITION  CALCULATION  (988) 


THROUGHPUT 


COMMUNICATION 

REQUIRED 


78.5  KOPS  10.7  KOPS  6  AT  100  Hz 


1  AT  10  Hz 


alignment/ 

CORRECTION  FILTER 


1.35  KOPS 


4  AT  1  Hz 


NAVIGATION 


2  AT  IP  Hz 


'measured  computation  time  1  MILLISECOND/ITERATION  OF  100  Hz  COMPUTATIONS  (DPI  bREADSOARDi 
"measured  computation  time  8  MILLISECOND/ITERATION  (DPI  BREADEOARD) 


(error  formatting  and  in-flight  Kalman  filter).  Some  of  these  functions 
have  been  implemented  in  the  software  for  the  DPI  breadboard  system 
and  the  measured  parameters  are  indicated  in  parentheses,  where 
available. 

4.1.2  Radiometric  Area  Correlation  Subsystem 

The  functions  of  the  RAC  subsystem  are  shown  in  the  block  diagram 
of  Figure  13.  This  subsystem  operates  in  conjunction  with  an  inertial 
reference  (IR),  for  weapon  guidance  and  may  be  used  in  both  midcourse 
and  terminal  flight  phases.  The  RAC  subsystem  correlates  sensed 
maps  with  pre- stored  reference  maps  to  determine  inertial  reference 
position  error  data.  The  coordinates  and  orientation  of  each  reference 
map  are  used  as  aimpoint  data  in  the  strapdown  inertial  reference  for 
weapon  trcijectory  control. 

The  weapon  position  and  attitude  data  from  the  inertial  reference 
and  reference  map  position  data  are  used  in  the  scan  control  function  to 
dynamically  control  the  position  of  a  gimballed  radiometer.  The  radi¬ 
ometer  utilizes  a  resonant  scan  in  the  azimuth  plane,  and  the  scan 
control  function  controls  the  pitch  plane  position  of  the  scan  and  isolates 
the  scan  from  weapon  motion.  The  scan  control  function  also  provides 
sampling  pulses  to  the  sensed  map  generation  function. 

The  output  of  the  radiometer  is  continuously  input  to  the  sensed 
map  generation  function.  The  sampling  pulses  cause  the  radiometer 
output  to  be  sampled  and  stored  at  intervals  corresponding  to  the  reso¬ 
lution  cell  size  of  the  reference  map.  The  size  of  each  sensed  map 
varies  during  weapon  flight.  The  cell  size  also  varies  during  flight. 
Since  the  radiometer  antenna  aperture  is  fixed,  the  weapon  altitude 
must  be  controlled  to  ensure  that  the  available  resolution  is 
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commensurate  with  cell  size  requirements.  After  each  sensed  map  is 
stored,  the  correlator  function  determines  the  best  match  (highest 
correlation)  of  the  sensed  map  data  with  all  available  positions  of  the 
sensed  map  within  the  reference  map.  The  position  of  the  best  match 
relative  to  the  center  of  the  reference  map  corresponds  to  the  IK 
position  error  normalized  to  the  cell  size. 

The  candidate  digital  processing  functions  are  tht  scan  control  and 
the  correlator,  both  of  which  are  performed  digitally  in  the  develop¬ 
mental  model  of  this  subsystem.  The  scan  control  function  consists  of 
two  coordinate  transformations  which  determine  the  position  of  the 
desired  sensed  map  sample  points  in  antenna  coordinates.  The  sample 
point  coordinates  in  an  inertial  frame  are  first  transformed  to  the 
weapon  body  coordinate  frame  using  equations  defined  in  Lockheed 
report  TR-925.  This  transformation  uses  a  direction  cosine  matrix 
which  is  available  in  the  strapdown  inertial  reference  subsystem.  The 
transformation  from  body  to  antenna  coordinates  is  then  performed  on 
the  basis  of  measured  antenna  gimbal  angles.  The  sampling  pulses  are 
generated  with  1 00- microsecond  time  resolution  in  the  second  transfor¬ 
mation  when  the  antenna  position  matches  the  desired  coordinates.  The 
digital  processing  requirements  associated  with  the  scan  control  func¬ 
tions  are  shown  in  Table  3. 

Two  different  processing  algorithms  were  investigated  for  the  correla¬ 
tor  function.  These  algorithms  were  the  normalized  deviation  product 


OUTPUTS:  POSITION  ERROR  (2) 
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Figure  13,  Radiometric  Area  Correlator  Block  Diagram 


TABLE  3.  PROCESSING  REQUIREMENTS  -  RAC  SUBSYSTEM 


THROUGHPUT 


FUNCTION 

PROGRAM 

SIZE 

OPERAND 

MEMORY 

1 

SHORT 

LONG 

COMMUNICATION 

REQUIRED 

SCAN  CONTROL; 

INERTIAL-MISSILE 

COORDINATE  CONVERSION 

250 

85 

73  KOPS 

8  KOPS 

40  AT  100  Hz 

1  PULSE  AT  14  Hz 

6  AT  0.25  Hz 

SCAN  CONTROL 

INERTIAL-ANTENNA 

COORDINATE  CONVERSION 

300 

100 

455  KOPS 

138  KOPS 

7  AT  10  kHz 

12  AT  100  Hz 

4  AT  0.25  Hz 

1  PULSE  AT  10  kHz 

CORRELATOR 

I/FI 

175 

9.5-35K 

15.3  MOPS 

2.79  MOPS 

1  AT  448  Hz 

INrUIVI  MLOtJrll  1  nivi 

I/F2 

100 

30 

434  KOPS 

98  KOPS 

3  AT  10.9  kHz 

2  AT  1  Hz 

I/F3 

60 

15 

217  KOPS 

0 

1  AT  10.9  kHz 

CORRELAI  OR 

SSDA 

ALGORITHM 

100 

8.6-34K 

9.94  MOPS 

0 

1  AT  448  Hz 

moment  (NPDM)  used  in  the  RAC  developmental  model  and  the  sequen¬ 
tial  similarity  detection  algorithm.  The  operations  required  for  these 
algorithms  to  determine  each  correlation  value  (one  sensed  map  posi¬ 
tion  within  the  reference  array)  are  shown  in  Figure  14.  The  remain¬ 
der  of  the  correlator  function  requires  the  determination  of  the  best 
correlation  point  (maximum  value  for  NPDM,  minimum  value  for 
SSDA)  using  the  correlation  values  calculated.  The  SSDA  potentially 
allows  early  truncation  of  the  calculation  point  values,  since  the  accu¬ 
mulation  may  be  stopped  when  it  exceeds  the  previous  minimum  value 
(or  some  preset  threshold).  However,  this  advantage  was  not  assumed 
in  the  determination  of  processing  requirements  for  the  correlator 
function.  »' 

• 

Digital  processing  requirements  for  the  two  algorithms  (and  alter¬ 
native  interface  definitions  in  the  NPDM  algorithm)  are  shown  in 
Table  3.  These  numbers  are  based  on  a  requirement  to  calculate  1089 
correlation  points  for  a  32  x  32  sensed  array  within  0.  8  second. 

4 .  1 .  3  LORAN  Subsystem 

The  LORAN  subsystem  and  associated  functions  are  shown  in 
Figure  15.  The  designation  of  the  master  and  slave  stations  in  the 
LORAN  network  appropriate  to  the  weapon  mission  is  performed  during 
the  weapon  assembly  process.  The  receiver  processes  the  signals 
from  the  designated  stations  and  outputs  a  set  of  time  difference  data 
corresponding  to  the  differences  in  time- of- arrival  between  the  signals 
of  the  master  station  and  each  of  the  slave  stations.  The  time  differ¬ 
ence  data  are  then  processed  to  determine  the  receiver  position. 
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Figure  15.  LORAN  Subsystem  Block  Diagram 

Only  the  position  processing  is  a  candidate  digital  function  because 
the  digital  portions  of  the  receiver  functions  are  included  in  the  receiver 
packages  available  from  many  different  vendors.  Several  different 
algorithms  are  available  to  determine  the  weapon  position  from  the  time 
difference  data.  These  algorithms  involve  different  initialization  par¬ 
ameters  for  the  LORAN  network  and  are  mission  dependent.  The 
algorithm  used  in  the  study  operates  on  the  time  difference  data  to 
derive  weapon  position  relative  to  the  target  position  in  the  inertial 
reference  navigation  frame.  This  is  accomplished  by  first  subtracting 
the  measured  time  difference  for  each  slave  station  from  the  time  dif¬ 
ference  for  that  slave  at  the  target  position.  The  resultant  differences 
for  a  pair  of  slave  stations  are  transformed  to  latitude  and  longitude 
differences  using  gradient  data  corresponding  to  the  target  position  in 
the  LORAN  network.  The  gradient  data  were  assumed  to  be  input  either 
during  weapon  assembly  or  by  the  avionics  prior  to  weapon  launch.  The 
relative  position  data  are  output  to  the  inertial  reference  subsystem  to 
correct  IR  errors  as  discussed  in  4,  1.  1.  The  processing  requirements 
for  this  function  are  shown  in  Table  4. 

4.1.4  E-O  Data  Link  Subsystem 

The  function  of  the  E-O  data  link  subsystem  are  shown  in  Figure  16. 
The  characteristics  used  in  the  study  are  based  on  the  data  link  sub¬ 
system  of  the  GBU-15  weapon  system.  This  subsystem  provides  in-flight 
control  of  both  the  flight  control  subsystem  and  either  an  E-O  or  HR 
terminal  guidance  sensor  by  means  of  operator  action.  The  operator 
actions  are  based  on  his  monitoring  the  scene  within  the  view  of  the 
terminal  sensor.  This  is  accomplished  using  the  transmitter  portion 
of  the  data  link  to  send  the  terminal  sensor  video  signal  to  the  launch 
aircraft.  The  operator  controls  the  weapon  mode  by  means  of  command 
messages  which  are  processed  in  the  receiving  portion  of  the  data  link. 

Because  of  the  data  bandwidths  involved,  only'  the  message  decoding 
function  is  a  candidate  for  digital  processing.  This  function  requires 
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that  the  bits  in  th%!  command  m^jssagt;  be  decoded  tv.  dettmiine  its  con^ 
ponent  data  and  control  signals,  and  the  formatting  and  distribution  of 
the  signals  to  the  appropriate  subsystems.  The  requirements  for  this 
function  are  given  in  Table  5. 

TABLE  4.  PROCESSING  REQUIREMENTS  -  LORAN  SUBSYSTEM 


PROGRAM  SIZE; 

OPERAND  MEMORY; 
COMMUNICATION  REOUIRED 
THROUGHPUT; 


100 

50 

5  AT  1  Hj 

100  OPS  (SHORT) 
10  OPS  (LONG) 


TABLE  5.  PROCESSING  REQUIREMENTS  -  EO  DATA  LINK 


PROGRAM  SIZE; 

100 

OPERAND  MEMORY; 

20 

COMMUNICATION  REQUIRED 

(4  +  11  LOGIC)  AT  30  Hz 

THROUGHPUT; 

17  KOPS  (SHORT) 

XMTR 


SEEKER 


Figure  16.  Electro -Optical  Data  Link  Subsystem  Block  Diagram 


4.1.5  TERCOM  Subsystem 

The  functions  of  the  TERCOM  (terrain  contour  matching)  subsystem 
are  shown  in  Fluurp  17.  This  subsystem  matches  measured  terrain 

contourMstrip  map)  with  stored  reference  data  to  determine  weapon 

position  errors.  The  output  of  the  radar  terrain  sensor  (radar  altimeter) 
L  sampU'i  rh»  weapw>n  position  data  from  the  inertial  reference 

match  the  position  of  the  stored  reference  data.  The  reference  altitude 
sensor  (ba^metric  altimeter)  is  also  sampled  to  measure 
altitude.  The  vertical  accelerometer  data  provide  isolation  of  vertical 
weapon  motion  during  strip  map  generation.  These  data  are  co^^^ine 
to  determine  terrain  elevation  at  each  sample  point. 
each  strip  map  is  assumed  to  be  a  sequence  of  data  f^oni  64  sample 
points.  The  strip  map  data  are  then  filtered  to  remove  both  mean 
elevation  and  mean  elevation  rate.  The  resulting  map  data  are  then 
correlated  with  the  stored  reference  data  to  find  the  best  position  match. 
The  deviation  of  the  match  point  relative  to  the  center  of  the  reference 
data  Is  the  position  error  normalized  to  the  map  cell  size. 

The  candidate  digital  processing  functions  for  this 
the  filtering  of  strip  map  data  and  the  contour  matching.  The  f lit e  g 

function  is  performed  by  a  51 -point  transversal  filter ,  requiring  a 
total  of  114  data  samples  for  each  strip  map.  The  contour  matching  is 
performed  by  a  one-dimensional  implementation  of  the  SSDA  discussed 
L  subsection  4.  1.  2.  The  allowable  time  to  perform  these  functions  was 
assumed  to  be  4  seconds  in  deriving  the  requirements  shown  in  lable  6. 


OUTPUTS;  POSITION  ERRORS  (2) 


Figure  17.  TERCOM  Subsystem  Block  Diagram 


29 


TABLE  6.  PROCESSING  REQUIREMENTS  -  TERCOM  SUBSYSTEM 


FUNCTION 

PROGRAM 

SIZE 

OPERAND 

MEMORY 

THROUGHPUT 

COMMUNICATION 

required 

SHORT 

LONG 

FILTERING 

50 

100 

1.1  KOPS 

0.16  KOPS 

1  AT  3  Hz 

3  AT  100  Hz 

POSITION  ERROR 

100 

1755  + 

(10. 5K  BULK) 

235  KOPS 

8  OPS 

1584  AT  1/300  Hz* 

2  AT  0.25  Hz 

TRANSFER  OF  REFERENCE  DATA  FROM  BULK  STORAGE  TO  OPERAND  MEMORY 


4.1.6  DME  Subsystem 

The  DME  subsystem  consists  of  a  transmitter  and  command 
receiver  which  operate  as  a  transponder,  enabling  aircraft  or  ground 
stations  to  determine  weapon  range  data  which  are  used  to  calculate 
weapon  position  in  three  coordinates.  The  computations  relating  weapon 
and  target  position  are  performed  by  one  of  the  airborne  or  ground  sta¬ 
tions  to  generate  weapon  steering  commands.  These  steering  commands 
are  transmitted  to  the  weapon  DME  subsystem  by  means  of  an  RE  link, 
decoded  and  formatted  for  use  by  the  flight  control  subsystem. 

The  only  candidate  digital  processing  function  is  the  decoding  and 
formatting  of  the  command  data.  Insufficient  information  on  the  char- 
acterisitcs  of  this  function  was  available  to  assess  the  associated 
processing  requirements.  However,  the  requirements  for  these  func¬ 
tions  in  the  E-O  data  link  subsystem  should  be  representative, 

4.1.7  Global  Positioning  System  (GPS)  Subsystem 

The  GPS  guidance  concept  utilizes  the  transmissions  from  four 
earth-orbiting  satellites  to  measure  range  to  each  satellite  and  thus 
determine  missile  position  in  three  coordinates.  The  concept  provides 
jam- resistant  operation  by  relying  heavily  on  the  integration  with  an 
onboard  inertial  reference,  coupled  with  pseudorandom  coded  satellite 
signals.  The  functional  relationship  of  the  GPS  receiver,  including 
the  receiver  process  controller  (RPC),  with  other  missile  subsystems 
is  shown  in  Figure  18.  (See  Table  7.  ) 

■A-  more  detailed  illustration  of  the  principal  GPS  guidance  proces¬ 
sing  functions  and  their  functional  relationship  is  shown  in  Figure  19. 

GPS  receivers  which  have  been  designed  for  aircraft,  ship,  and  man- 
pack  applications,  provide  digital  measurements  of  pseudorange 
(prefixed  "pseudo”  because  the  measurements  are  relative  signal  time- 
rather  than  absolute  range)  and  delta  range  with  the  precise 
time  of  reception.  These  pseudorange  measurements,  after  correction 
for  known  timing  errors,  are  then  utilized  by  the  guidance  (suboptimal) 
filter  to  compare  with  an  internally  derived  estimate  of  satellite  ranges. 


30 


TABLE  7.  GPS  GUIDANCE  SUBSYSTEM  DIGITAL  PROCESSING 

REQUIREMENTS 


THROUGHPUT;  300  KOPS 
COMPUTATION  WORD  LENGTH;  16  BITS 
DOUBLE  PRECISION  CAPABILITY 


INSTRUCTION  SET:  GENERAL  PURPOSE 
INTERRUPT  CAPABILITY 
DIRECT  MEMORY  ACCESS 


FUNCTION 

SUBOPTIMAL  FILTER 

RECEIVER  DATA  PROCESSING 

RECEIVER  AIDING 
OUTPUT  DATA  PROCESSING 

INERTIAL  NAVIGATION 

EXECUTIVE 

INTERRUPT  HANDLING 
I/O  ROUTINES 
INITIALI2ATION 
SELF  TEST 

SUBROUTINE  LIBRARY 


MEMORY  REQUIREMENT 


GUIDANCE  PROCESSING  FUNCTIONS 


rUOHT 

CONTROL 


Irate  aiding  signalsI 


|l0/t*c  TO  100/MC 


Figure  18,  GPS  Subsystem  Functional  Flow  Diagram 

The  differences  in  range  are  then  used  by  the  filter  to  estimate  current 
errors  in  position  and  velocity  as  well  as  the  magnitude  of  the  most 
probable  causes  of  navigation  error  (such  as  misalignment).  The 
precise  measurements  of  signal  reception  time  are  required  by  the 
ephemeris  calculations  to  accurately  determine  the  position  and  velocity 
of  each  satellite  at  the  time  of  transmission.  The  estimated  inertial 
navigation  errors  provided  by  the  guidance  filter  are  then  used  to  update 
the  best  estimates  of  missile  position  and  velocity. 
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Figure  19.  Principal  GPS  Guidance  Processing  Functions 


The  position  and  velocity  estimates  from  the  inertial  navigation 
function  are  used  by  the  guidance  law  to  generate  steering  commands  as 
input  to  the  autopilot  or  flight  control  function.  This  same  position  and 
velocity  information  is  also  used  to  perform  the  receiver  acquisition 
control  and  rate-aiding  functions.  The  receiver  acquisition  control 
function  must  also  accept  the  initialization  and  acquisition  data  from 
the  aircraft  GPS  (HD)  set  and  control  initial  receiver  acquisition. 

Estimates  of  the  digital  processing  requirements  were  made  by 
modifying  the  estimated  processing  requirements  for  the  current  SAMSO 
aircraft  receiver  demonstration  program  system,  taking  into  account 
the  differences  in  functional  requirements  between  the  aircraft  naviga¬ 
tion  and  missile  guidance  problems.  Several  factors  have  combined  to 
cause  the  memory  requirement  estimates  to  be  conservative.  Firstly, 
the  computer  programs  have  been  written  in  a  higher-order  language, 
resulting  in  inefficiency  in  generating  the  resultant  machine  language 
program.  The  developmental  nature  of  the  SAMSO  demonstration 
system  required  additional  programming  for  system  test  and  instrumen¬ 
tation  data  collection.  Also,  no  optimization  of  developmental  software 
is  warranted.  Therefore,  significant  uncertainty  remains  regarding 
the  actual  requirements  for  a  tactical  weapon.  Further  development  of 
actual  missile  processing  algorithms  and  corresponding  software  must 
be  undertaken  to  create  a  more  accurate  requirements  estimate. 

4.  2  TERMINAL  GUIDANCE  SUBSYSTEMS 

The  generic  characterization  of  the  terminal  guidance  subsystems 
of  this  weapon  system  is  shown  in  Figure  20.  Most  terminal  guidance 
techniques  utilize  some  type  of  onboard  target  sensor  for  improved 
guidance  accuracy.  This,  in  turn,  implies  that  the  sensor  must  be 
pointed  at  the  target,  and  that  the  target  characteristics  must  be 
supplied  to  the  guidance  processing. 
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Figure  20,  Terminal  Guidance  Characterization 


Sensor  pointing  data  can  be  derived  by  onboard  computations  on 
the  basis  of  weapon  and  target  position  data  from  a  midcourse  guidance 
subsystem,  e.  g.  ,  inertial  reference.  Alternatively,  sensor  pointing 
data  can  be  supplied  by  operator  action,  e.  g.  ,  E-O  seeker  slew  com¬ 
mands  by  means  of  the  umbilical  or  E-O  data  link. 

The  data  from  the  target  sensor  are  processed  io  discriminate 
between  target  and  background.  This  discrimination  process  is  based 
on  target  parameters  which  may  be  preselected  in  the  subsystem  or 
inserted  as  initial  conditions.  In  some  subsystems,  measured  target 
parameters  are  used  to  update  the  initial  conditions  for  improved 
discrimination. 

Sensor  pointing  information,  usually  line  of  sight  (LOS)  angle  or 
LOS  rate,  is  processed  through  a  guidance  law  to  control  weapon  tra¬ 
jectory  by  means  of  the  flight  control  subsystem. 

4.  2.  1  Electro- Optical  and  Imaging  Infrared  Seeker  Subsystems 

The  functions  of  the  E-O  and  IIR  subsystems  and  associated  sub¬ 
systems  are  shown  in  Figure  21.  The  functions  of  these  two  seeker 
subsystems  are  essentially  identical  with  the  primary  differences  being 
in  the  implementat' "'is  of  the  sensor  and  scan  converter  functions.  The 
outputs  of  the  scan  converter  are  wideband  video  signals  which  are  sent 
to  the  video  processor  and  to  the  E-O  data  link  subsystem  (see  subsec¬ 
tion  4.  1.4).  The  video  processor  amplifies  the  analog  video  signal  to 
normalized  level  for  input  to  the  threshold  function  which  discriminates 
between  target  and  background.  The  threshold  output  is  sent  to  the 
tracking  function  which  derives  signals  for  steering,  sensor  pointing, 
and  video  processor  control. 
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Figure  21.  EO/HR  Seeker  Block  Diagram 


The  candidate  digital  processing  functions  for  these  subsystems  are 
the  control  of  the  video  processor,  the  thresholding,  and  the  target 
tracking.  Two  algorithms  which  perform  these  functions  were  investi¬ 
gated  in  this  study.  One  algorithm  is  used  in  the  ATVS  system  under 
development  by  the  Army.  The  second  algorithm  is  the  mathematically 
optimum  for  discrimination  between  target  and  a  Gaussian  background. 
The  two  algorithms  are  presented  in  Figures  22  and  23.  The  processing 
requirements  associated  with  these  two  algorithms  are  shown  in  Fig- 
ure  24  for  various  partitioning  between  special  purpose  processing  and 
general  purpose  processing. 

4^  2.  2  Radiometric  Contrast  Seeker  Subsystem 

The  functions  of  the  radiometric  contrast  seeker  subsystem  are 
shown  in  Figure  25.  Target  line  of  sight  data  is  used  to  point  the 
gimballed  sensor  to  the  designated  target.  For  inflight  acquisition, 
this  information  can  be  derived  from  the  inertial  reference  vveapon 
position  data  and  the  target  position  initial  condition.  The  wideband 
output  of  the  sensor  is  amplified  in  the  receiver,  and  target  discrimi¬ 
nation  is  performed  by  detecting  the  derived  sensor  pointing  error 
signals  which  control  the  sensor  position.  The  pointing  error  data  are 
output  to  the  flight  control  subsystem  as  steering  commands. 

Based  on  a  developmental  model  of  this  type  of  seeker,  the  proces¬ 
sing  bandwidth  is  very  wide  (-500  MHz)  through  the  receiver  function. 
Only  the  target  discrimination  and  sensor  control  functions  are  amenable 
to  digital  techniques.  However,  the  definition  of  these  functions  does 
not  imply  any  advantage  for  digital  processing,  so  only  interfacing 
requirements  at  the  subsystem  level  are  applicable. 
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Figure  22.  ATVS  Tracking  Algorithm 
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TRACKING  ALGORITHM 

PROGRAM 

SIZE 

OPERAND 

MEMORY 

THROUGHPUT 

COMMUNICATION 

REQUIRED 

SHORT 

LONG 

ATVS  BASED 
INTERFACE (T) 

250 

35 

111  AT  LINE 
180  AT  60  Hz 

5  AT  LINE 

11  AT  60  Hz 

14  AT  LINE 

13  AT  60  Hz 

ATVS  BASED 
INTERFACE  @ 

200 

35 

10.8  KOPS 

0.66  KOPS 

18  AT  60  Hz 

OPTIMAL 

INTERFACE  (T) 

240 

40 

34  AT  LINE 

175  AT  60  Hz 

2  AT  LINE 

18  AT  60  Hz 

5  AT  LINE 

12  AT  60  Hz 

OPTIMAL 

INTERFACE @ 

205 

40 

10.5  KOPS 

1.08  KOPS 

17  AT  60  Hz 
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Figure  24. 
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Figure  25,  Radiometric  Contrast  Seeker  Block  Diagram 


4.  2.  3  Semiactive  Laser  Seeker  Subsystem 


The  functions  of  the  semiactive  laser  seeker  subsystem  are  shown 
in  Figure  26.  This  subsystem  operates  in  conjunction  vTth  an  indepen¬ 
dent  source  of  pulsed  laser  energy  which  illundnates  the  target.  The 
initial  conditions  supplied  by  the  avionics  are  the  target  line  of  sight 
and  the  pulse  repetition  frequency  (PRF)  of  the  laser  illuminator.  The 
sensor  is  a  gimballed  four-quadrant  detector  which  is  directed  toward 
the  target  using  the  initial  condition  data.  The  outputs  of  the  four 
quadrants  are  separately  amplified  in  the  receiver  and  then  combined 
in  a  sum  and  difference  network.  The  target  discrimination  operates  on 
the  sum  output  to  detect  the  last  pulse  within  a  fixed  gate  at  the  designated 
PRF,  The  position  of  the  target  pulse  within  the  gate  is  used  to  control 
the  gate  timing  for  the  next  pulse.  The  difference  channel  data  at  the 
target  pulse  time  rnrreAponde  to  rhe  nsor  pulntLcig  t’Ti'or  infunutiun 
in  the  two  axes  and  is  used  for  both  sensor  pointing  control  and  for 
steering  the  weapon. 

The  characteristic  bandwidth  of  all  processing  through  the  target 
detection  and  pointing  error  derivation  is  approximately  50  MHz  which 
is  not  compatible  with  current  digital  processing  technology.  The 
definition  of  the  remaining  functions  does  not  imply  any  advantace  for 
digital  implementation,  so  only  interfacing  functions  at  the  subsystem 
level  are  applicable. 

4.2.4  Anti- Radiation  Seeker  Subsystem 

The  functions  of  the  antiradiation  seeker  subsystem  are  shown  in 
Figure  27.  This  seeker  operates  on  received  RF  energy  and  develops 
signals  for  weapon  guidance  to  the  designated  radar  source.  Initial 
conditions  supplied  by  the  avionics  designate  the  radar  source 
characteristics  —  LOS,  transmission  frequency,  PRF,  pulse  width, 
and  intensity  —  to  the  appropriate  seeker  functions.  Initially,  the 
sensor  is  pointed  along  the  target  LOS,  and  the  receiver  is  tuned,  tc 
the  designated  frequency.  Pulses  at  the  desired  frequency  are  ampli¬ 
fied  by  the  receiver  and  sent  to  the  target  discrimination  function  which 
selects  the  pulses  from  the  designated  source  on  the  basis  of  PRF, 
pulse  width,  and  intensity.  Sensor  pointing  error  information  is 
developed  to  close  the  seeker  control  loop  and  for  weapon  steering. 

The  source  signal  characteristics  are  updated  using  the  measured 
pulse  parameters  both  for  improved  discrimination  and  to  aid  in  signal 
reacquisilio'n,  if  required. 

The  target  discrimination  function  was  studied  to  determine  digital 
processing  requirements.  The  bandwidths  of  the  sensor  and  receiver 
functions  exceed  digital  processing  capability,  and  some  seekers  of 
this  type  use  body- fixed  sensors  implying  that  the  sensor  control  func¬ 
tion  is  really  contained  in  the  target  discrimination  function.  The  dis¬ 
crimination  algorithms  used  in  this  study  are  based  on  the  signal  pro¬ 
cessing  for  HARM.  The  digital  processing  requirements  in  Table  8 
vary  with  system  level  requi'*'ementB  on  maaimuzn  Lopul  pulit-  tifi'aalty 
from  which  the  desired  pulse  train  must  be  discriminated.  Consequently, 
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Figure  26,  Semiactive  Laser  Seeker  Block  Diagram 
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TABLE  8.  PROCESSING  REQUIREMENTS  -  ANTIRADIATION  SEEKER 


PROGRAM  SIZE  : 

640 

OPERAND  MEMORY 

150 

COMMUNICATION  REQUIRED; 

6  AT  PRF 

4  LOGIC  AT  PRF 

THROUGHPUT: 

INVALID  PULSE  REJECTION 

-  18  SHORT/T.|  • 

VALID  PULSE  PROCESSING 

-  (135  SHORT  +  18  LONG) 

PRF 

RE  ACQUISITION 

-  (75  SHORT  +  2  LONOPRF 

•T,  -  ARRIVAL  TIME  DIFFERENCE.  SECONDS.  BETWEEN  INVALID  AND  VALID  PULSES, 

PRF  -  PULSE  REPETITION  FREQUENCY  OF  DESIRED  PULSE  TRAIN. 

throughput  requirements  are  shown  in  terms  of  the  worst  case  number 
of  instructions  which  are  executed  for  the  processes  involved  in  the 
discrimination  function. 


4.  3  FLIGHT  CONTROL  SUBSYSTEM 


The  functions  of  the  flight  control  subsystem  are  shown  in  Figure  28. 
The  two  basic  functions  performed  by  the  flight  control'  are  stabilization 
and  steering.  The  stabilization  function  maintains  airframe  stability 
during  weapon  flight  by  deriving  commands  for  the  flipper  actuators  on 
the  basis  of  measured  angle  rates  of  the  airframe. 


ACTUATORS 


Figure  28.  Flight  Control  Subsystem  Block  Diagram 
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The  steering  function  operates  on  steering  commands  supplied  by 
guidance  subsystems  as  some  combination  of  attitude  or  acceleration 
commands.  The  outputs  of  the  steering  and  stabilization  functions  are 
combined  to  form  commands  'u  the  actuator  subsystems. 

Considerable  variations  occur  in  both  functions  depending  on  weapon 
airfrariie  configuration,  phase  of  flight,  and  type  of  guidance  subsystem. 
These  variations  require  changes  in  both  the  form  of  processing  to  be 
performed  and  the  processing  parametets  of  the  flight  control  subsystem, 
night  control  mode  control  and  parameter  selection  is  pertormed  by  tne 
logic  and  control  function  shown. 

The  processing  requirements  for  the  flight  control  functions  show'n 
in  Table  9  are  based  on  the  GBU-15  weapon  system  as  implemented  in 
PDAP.  The  PDAP  requirements  have  been  modified  to  account  for 
differences  in  system  requirements. 

TABLE  9.  PROCESSING  REQUIREMENTS  -  FLIGHT  CONTROL 


THROUGHPUT 


FUNCTION 

PROGRAM 

SIZE 

OPERAND* 

MEMORY 

SHORT 

LONG 

COMMUNICATION 

REQUIRED 

STABILIZATION 

70 

65 

140  KOPS 

B  KOPS 

6  AT  400  Hz 

STEERING 

120 

76 

22  KOPS 

1.B  KOPS 

4  AT  50  Hz 

LOGIC  AND  CONTROL 

100 

20 

10  KOPS 

0 

1  AT  50  Hz 

COMMON  SUBROUTINES 

400 

•  « 

•  • 

•  » 

0 

ADDITIONAL  AIRFRAME: 

f  <70  PM  FOR  stabilization! 

<120  PM  FOR  STEERING 
<100  PM  FOR  LOGIC 


t  100  CONSTANT 
MEMORY 


100  CONSTANT  MEMORY  PARAMETERS  IN  ADDITION  TO  DATA  VARIABLE  REOUIREMENTS  SHOWN 
‘included  IN  ABOVE  ENTRIES 


4.4  ARMAMENT  SUBSYSTEM 

The  armament  subsystem  consists  of  a  fuze  and  a  warhead.  The 
processing  requirements  identified  for  this  subsystem  were  parameter 
setting  and  status  determination.  A  detailed,  examination  of  the  require¬ 
ments  on  these  functions  indicated  no  advantage  for  the  iniplementation 
in  the  digital  processor.  Therefore,  the  only  digital  processing  require¬ 
ments  fwr  this  subsystem  are  associated  with  data  distribution. 


4.5  AIRCRAFT  INTERFACE 


The  function  of  the  aircraft  interface  is  to  provide  mission-related 
parameters  to  the  weapon  subsystems.  The  type,  number,  and  format 
of  the  parameters  are  strictly  dependent  on  the  weapon  configuration, 
i.  e.  ,  the  component  subsystems.  Examples  of  these  parameters  have 


been  discussed  for  each  subsystem  in  the  previous  paragraphs.  In 
order  to  provide  the  appropriate  parameters,  the  avionics  subsystem 
must  have  knowledge  of  the  weapon  configuration.  Several  alternatives 
are  available  to  provide  configuration  information  for  each  weapon 
station  on  the,  aircraft:  weapon  control  officer  inputs  (from  mission  plan), 
launcher  data  (set  during  weapon  up-loading)  and  data  directly  from  the 
weapon.  Regardless  of  the  method  used,  status  data  from  the  weapon 
are  required  to  ensure  that  the  avuonics  data  have  been  correctly 
received  and  were  the  ie4ulred  daLci  foi  tht,  wt-ajjon  conliguratii^ii. 

The  digital  processor  functions  associated  with  this  interface  are 
tht  formatting  and  distribution  nf  and  control  signals  between  the 

avionics  and  the  weapon  subsystem.  The  requirements  for  these  func¬ 
tions  are  strictly  configuration  dependent,  not  only  in  terms  of  the 
weapon  but  also  for  the  avioi  cs,  which  may  be  either  analog  (existing 
avionics)  or  digital  (DAIS,  SMS).  The  stores  management  system  (SMS) 
interface  specification  was  used  in  this  study  to  define  both  the  functional 
and  electrical  interface  parameters  for  digital  avionics.  It  is  expected 
that  analog  avionics  rr^ay  only  be  capable  of  operation  with  a  subset  of 
all  possible  weapon  configurations,  since  some  weapon  subsystem  para¬ 
meters  may  not  be  available  in  the  avionics  These  factors 

will  be  discussed  in  more  detail  in  a  later  section. 
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SECTION  V 

POINT  DESIGN  FOR  WEAPON  CONFIGURATIONS 


In  Section  IV,  the  role  of  a  digital  processor  in  a  subsystem  was 
discussed.  For  each  of  the  applicable  subsystems,  several  functional 
partitionings  were  made  and  the  digital  processing  requirements  corres¬ 
ponding  to  each  interface  were  determined.  Selection  of  the  appropriate 
interface  depends  to  some  extent  on  whether  the  digital  processor  is  just 
a  subsystem  component  or  whether  it  is  a  system  component.  In  the 
latter  case,  other  tasks  are  assigned  to  it  and,  for  system  or  economic 
reasons,  it  may  be  appropriate  to  choose  a  different,  less  demanding 
interface  than  if  it  were  a  part  of  the  subsystem. 

The  role  of  the  digital  processor  in  the  total  weapon  system  varies 
with  the  type  of  weapon  system.  Two  system  extremes  are  a  fixed 
design  weapon,  such  as  Maverick,  and  a  modular  weapon  with  a  com¬ 
plex  array  of  possible  subsystems.  The  latter  type  of  weapon  system 
is  the  object  of  this  study.  However,  in  order  to  gain  an  appreciation 
lor  the  use  of  a  digital  processor  in  a  modular  weapon,  it  is  instructive 
to  examine  its  use  in  a  fixed  design. 

In  this  section,  three  point  designs  are  defined,  corresponding  to 
the  three  weapon  configurations  selected  in  Section  II.  Interfaces  with 
each  of  the  subsystems  are  chosen,  and  the  digital  processing  require¬ 
ments  for  the  system  are  determined,  A  criterion  for  the  selection  of 
the  interfaces  was  to  maximize  the  amount  of  processing  assigned  to 
the  digital  processor  subject  to  the  capability  of  current  technology. 

The  result  should  be  the  most  economical  design  for  that  particular 
weapon. 

The  three  point  designs  arrived  at  in  this  section  set  the  stage  for 
a  discussion  of  the  role  of  a  digital  processor  in  a  modular  weapon, 
which  is  the  subject  of  the  following  section. 

5.  1  DESIGN  GROUND  RULES  FOR  POINT  DESIGNS 


The  three  configurations  for  which  point  designs  are  defined  are 
listed  in  Table  10.  The  ground  rules  for  the  designs  are: 

1.  Each  design  is  to  be  separately  optimized. 

2.  Within  each  design,  the  total  processing  load  is  to  be  partitioned 
between  analog  and  digital  with  the  object  of  tT'aximizing  the  amount  of 
digital  processing  subject  to  the  present  digital  state  of  the  art, 

3.  The  processing  assigned  to  digital  equipment  is  further  parti¬ 
tioned  between  special  purpose  aigital  equipment  (assigned  to  the  sub¬ 
system)  and  a  central  digital  processor  which  exercises  system  soft¬ 
ware  control. 

4.  There  is  a  harness  which  connects  the  central  processor  to 
the  subsystems.  The  link  to  each  subsystem  is  dedicated  (not  shared 
with  other  subsystems)  and  is  optimized  for  that  subsystem. 
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5.  All  signal  format  conversions  (e.  g.  ,  analog-to-digital)  are 
performed  autonomously  in  the  appropriate  subsystem. 

6.  The  subsystems  have  access  to  the  processor  through  a  hard¬ 
ware  priority  interrupt  system. 

7.  There  is  no  softw'are  executive.  Task  assignment  in  the 
processor  is  by  way  of  the  hardware  priority  interrupt  system. 

The  throughput  requirement  arrived  at  for  each  of  the  systems  is 
the  average  throughput  which  is  the  sum  of  the  average  throughput 
requirement  for  each  task.  This  may  be  taken  as  the  peak  throughput 
requirement  also  if  two  assumptions  are  satisfied: 

1.  Propagation  delay  requirements  for  any  particular  function  are 
compatible  with  the  given  throughput,  considering  the  function  by  itself. 

2.  Any  function  with  significant  propagation  delay  requirements 
can  be  assigned  a  high  enough  priority  to  assure  meeting  its  requirement. 

If  the  assumptions  do  not  hold,  the  given  throughput  requirements  would 
have  to  be  increased  to  accommodate  propagation  delay  requirements. 

TABLE  10.  WEAPON  CONFIGURATIONS 


CONFIGURATION 

t 

Ml 

AIRFRAME 

CRUISE 

PWW 

cww 

MIDCOURSE  GUIDANCE 

RAC/IMU 

LORAN 

DME 

TERMINAL  GUIDANCE 

RAC/IMU 

EO 

MR 

FUZE 

DIGITAL 

DIGITAL 

DK.ITAL 

5.2  WEAPON  CONFIGURATION  POINT  DESIGN 
5.2.  1  Weapon  Configuration  I 

The  functional  block  diagram  for  this  configuration  is  shown  in 
Figure  29.  The  partitioning  of  the  system  is  indicated  by  the  letters 
in  the  right  hand  corner  of  each  box.  The  rationale  for  the  partitioning 
is  based  on  the  discussion  of  the  subsystems  given  in  Section  IV.  The 
throughput  requirements  for  the  given  interfaces  are  also  listed  in 
that  section.  The  combinations  of  the  functions  which  are  operative  as 
a  function  of  mission  phase  and  the  resulting  throughput  requirements 
are  shown  in  Figure  30.  The  principal  variations  in  processing  con¬ 
figuration  during  weapon  flight  are  in  the  parameter  inputs  to  the  navi¬ 
gation  function.  The  weapon  trajectory  is  controlled  according  to  the 
position,  cell  size,  and  orientation  of  the  stored  reference  array  data. 
These  reference  data  determine  an  appropriate  aimpoint  and  approach 
angle  for  the  weapon  during  flight.  After  the  last  position  error  data 
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Figure  30.  Throughput  Requirements  —  Configuration  I 


are  obtained,  the  aimpoint  is  set  to  the  target  coordinates,  and  the 
desired  approach  angle  is  set  for  best  warhead  effectiveness.  Target 
coordinates  may  be  input  by  the  avionics  during  the  prelaunch  phase  or 
may  be  input  to  the  reference  data  storage  during  weapon  assembly. 
The  fuze  is  enabled  at  the  appropriate  weapon-target  range. 

5.2.2  Weapon  Configuration  II 

The  functions  of  this  weapon  configuration  are  shown  in  Figure  31 
and  the  processor  throughput  requirements  as  a  function  of  mission 
phase  are  shown  in  Figure  32.  The  target  coordinates  (avionics  input 
during  prelaunch)  are  used  with  the  calculated  weapon  position  in  the 
navigation  function  for  yaw  plane  steering  during  midcourse.  The  cal¬ 
culated  LORAN  position  data  are  used  to  correct  the  weapon  attitude, 
velocity,  and  position  data  during  this  phase. 
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Figure  32.  Throughput  Requirements  —  Configuration  II 


The  transition  from  midcourse  to  terminal  is  based  on  commands 
from  the  data  link.  In  the  terminal  mode,  the  E-O  steering  signals  are 
used  for  weapon  guidance.  The  fuze  is  enabled  by  data  link  command. 


5.  2.  3  Weapon  Configuration  III 


The  functions  of  this  weapon  configuration  are  shown  in  Figure  33 
and  the  processor  throughput  requirements  as  a  function  of  mission 
phase  are  shown  in  PTgure  34.  Midcourse  guidance  utilizes  either  data 
link  (DL)  or  DME  steering  commands  as  determined  by  the  status  sig¬ 
nals  received  from  these  subsystems  (current  GBU-15  guidance  mode). 
The  transition  to  terminal  mode  which  uses  the  HR  steering  signals 
for  guidance  is  by  command  from  the  data  link.  The  fuze  is  also 
enabled  by  data  link  command. 


5.2.4  Configuration  Requirements  Summary 


The  processing  requirements  for  each  of  the  three  weapon  configura¬ 
tion  designs  are  shown  in  Table  11.  These  requirements  represent  the 
worst  case  combination  of  functions  during  the  typical  mission  for  these 
configurations. 


THROUGHPUT,  KOPS 


TABLE  11.  CONFIGURATION  PROCESSING  REQUIREMENTS  SUMMARY 


CONFIGURAT  ION 

PROGRAM 

SIZE 

OPERAND 

MEMORY 

THROUGHPUT,  KOPS  | 

SHORT 

LONG 

1 

2540 

850 

814 

.  125 

II 

2630 

750 

864 

48 

III 

1030 

320 

492 

26 

FUNCTIONS 
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STABILIZATION 

STEERING 

LOGIC 

MESSAGE  DECODING 


+  FIELD  PROCESSING - 

—  + 

LINE  PROCESSING  - 


Figure  34,  Throughput  Requirements  —  Configuration  III 


It  is  noted  that  the  requirements  for  the  third  configuration  are  much 
less  than  for  the  first  two.  In  other  words,  a  processor  optimized  for 
Configuration  III  would  not  be  suitable  for  the  other  two  configurations. 
However,  a  single  processor  could  nicely  satisfy  the  requirements  for 
the  first  two  configurations. 

5.3  INTEGRATION  IN  POINT  DESIGNS 


Up  to  this  point,  an  integration  function  in  the  point  designs  has 
not  been  explicitly  considered.  It  is  clear  that  the  digital  processor 
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WEAPON  CONFIGURATION 


SIGNAL  TYPE 


3  AT  400  Hz 

4  AT  50  Hz 


3  AT  400  Hz 
1  AT  10  Hz 


3  AT  400  Hz 
1  AT  10  Hz 


ANALOG  INPUTS 


3  AT  400  Hz 
2  AT  60  Hz 
2  AT  30  Hz 


3  AT  400  Hz 
2  AT  60  Hz 
2  AT  30  Hz 


ANALOG  OUTPUTS 


5  AT  4  8  kHz 
2  LOGIC  AT  50  Hz 
2  AT  30  Hz 


5  AT  15,75  kHz 

6  AT  100  Hz 
2  AT  30  Hz 
2  AT  1  Hz 


3  AT  10.9  kHz 
8  AT  100  Hz 
1  LOGIC  AT  100  Hz 
8  AT  1  Hz 


DIGITAL  INPUTS 


8  AT  60  Hz 
1  LOGIC  AT  50  Hz 


8  AT  60  Hz 
1  LOGIC  AT  50  Hz 


28  AT  100  Hz 
1  LOGIC  AT  50  Hz 


DIGITAL  OUTPUTS 


1  AT  4.8  kHz 
1  AT  400  Hz 
1  AT  30  Hz 


1  AT  15.75  kHz 
1  AT  400  Hz 

1  AT  100  Hz 

2  AT  30  Hz 


1  AT  10,9  kHz 
1  AT  400  Hz 
1  AT  100  Hz 


INTERRUPT  INPUTS 


(The  reverse  of  this  page  is  blank) 


TABLE  12,  INTERFACE  SIGNALS  FOR  POINT  DESIGNS 


has  a  key  role  in  the  integration.  It  not  only  does  some  of  the  compu¬ 
tations  for  the  various  subsystems,  but  it  also  distributes  the  results 
to  the  appropriate  place.  One  can  consider  the  harness  and  the  processor 
together  as  the  integration  subsystem  for  the  weapon.  The  harness  pro¬ 
vides  the  physical  link  to  each  of  the  subsystems  and  the  processor  is 
the  nexus.  It  functionally  links  the  subsystems  together  into  a  working 
system,  i.  e.  ,  it  provides  the  interface  between  all  the  subsystems.  Thi 
functional  interface  between  the  processor  and  the  various  subsystems 
is  summarized  in  Table  12,  which  lists  the  signals  entering  and  leaving 
the  processor.  The  interface  signals  are  categorized  by  format  (analog 
versus  digital)  and  data  rates  are  shown  for  each  type.  The  variations 
in  the  number  and  data  rate  of  each  type  of  interface  signal  over  the 
three  configurations  are  quite  apparent.  These  variations  are  a  result 
of  both  differences  in  the  type  of  functions  performed  in  the  three  con¬ 
figurations  and  differences  in  requirements  for  the  equivalent  functions. 


SECTION  VI 

THE  MODULAR  WEAPON  AND  INTEGRATION 

The  major  purpose  of  this  study  was  to  determine  the  role  of 
digital  processing  iu  integrating  the  components  of  a  modular  weapon 
system.  In  the  preceding  section,  the  part  played  by  a  digital  processor 
in  integrating  the  components  of  a  fixed-design  weapon  was  described. 

In  the  latter  situation,  the  integration  subsystem  is  a  combination  of  a 
digital  processor  and  a  harness  with  dedicated  links  to  the  subsystems. 

It  is  the  purpose  of  this  section  to  determine  the  corresponding  integra¬ 
tion  subsystem  for  a  modular  weapon,  and  to  determine  what  functions 
must  be  assigned  to  the  digital  processor  to  accomplish  integration. 

The  first  step  is  to  examine  the  characteristics  of  a  modular  weapon 
system. 

6.  1  MODULAR  WEAPON  CHARACTERISTICS 

The  salient  feature  of  the  modular  weapon  is  that  the  subsystem  of 
the  fixed-design  weapon  Is  replaced  by  a  generic  subsystem.  In  the 
assembly  process,  there  are  points  where  a  choice  is  possible.  For 
example,  it  is  not  the  terminal  guidance  section,  but  one  of  N  terminal 
guidance  sections.  The  fixed  interface  of  the  fixed-design  becomes  a 
variable  interface,  at  least  in  functional  detail.  The  real  integration 
problem  of  the  modular  weapon  is  to  control  this  variable  interface, 

6.1.1  Description  of  Modular  Weapon  (Weapon  Assembly  Level) 

It  is  assumed  that  the  weapon  system  is  stored,  (in  the  forward 
area)  as  sections  which  are  assembled  into  weapons  as  the  need  arises. 
An  assembled  weapon  might  be  described  as 

Ai  -  B3  -  Cl  -  Di  -  E2  -  F^. 

This  is  interpreted  as  a  weapon  with  the  nose  section  of  the  first  type 
(Ai),  the  second  section  of  the  third  type  (B3),  and  so  on.  It  is  not 
required  that  each  spot  in  the  sequence  be  filled  for  all  weapon  configura¬ 
tions.  The  modularity  concept  requires  that 


might  be  a  weapon  configuration  also.  The  deleted  segment  could  be  a 
propulsion  module.  Also  required  by  the  modularity  concept  is  some 
degree  of  interchangeability  of  the  section  sequence.  For  example, 
weight  and  balance  considerations  may  require  a  weapon  like 


Also  admitted  into  the  modularity  concept  are  two  other  kinds  of  con¬ 
structions;  bolt-ons  and  slip-ins.  A  bolt-on  is  a  module  that  bolts  on 
to  one  of  the  sections.  The  purpose  could  be  to  modify  the  aerodynamics 
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or  to  add  propulsion.  In  the  above  notation,  a  bolt-on  fastened  to 
section  Dj^  would  be  designated  as 


D! 

J 

D.  - 
1 


which  is  interpreted  as  the  choice  of  bolt-on  for  section  Dj^. 

A  slip-in  is  a  subsystem  which  is  optionally  placed  in  a  section. 

It  is  thought  that,  in  general,  sections  will  be  complete  as  delivered  to 
the  forward  area.  However,  it  allows  a  bit  more  flexibility  in  the 
modularity  concept  if  slip-ins  are  allowed.  An  example  of  a  slip-in 
might  be  an  altimeter  which  would  be  required  in  only  a  lew  coniigura- 
tions.  In  the  above  notation  a  slip-in  would  be  designated  by  an  inferior 
letter: 

-  D.  - 
1 

D!' 

J 

where  Dj'  represents  the  choice  of  a  slip-in  for  the  section. 

In  summary,  then,  the  modularity  concept  used  in  this  study 
(expressed  at  the  section  level)  allows  constructions  like 


D 


1 


A,  -  B,  -  C,  -  D_  -  E. 
113  2  4 


with  the  possibility  of  interchanging  section  positions.  That  is,  C^-D! 
can  become  Dj-C[. 

The  spirit  of  modularity  demands  that  such  constructions  be 
accomplished  with  a  minimum  use  of  configuration  -  specific  adaptor 
modules  or  adjustments.  That  is,  it  is  undesirable  to  require  the 
assembler  to  have  to  select  special  adaptors  for  specific  sections  or 
subsystems.  It  is  also  undesirable  to  require  that  special  adjustments 
or  parameter  settings  be  made  on  selected  sections. 

Another  way  of  describing  the  modular  weapon  is  by  the  subsystems 
or  functions  it  contains.  The  generic  subsystem  list  contains  such  items 
as 


Warhead 
Airframe 
Propulsion 
Inertial  sensors 
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•  Flight  control 

•  Midcourse  guidance 

•  Terminal  guidance. 

Each  of  these  generic  subsystems  can  have  several  specific  choices. 

In  general,  there  is  a  close  relationship  between  the  subsystem  descrip¬ 
tion  and  the  section  description  for  the  weapon.  For  example,  almost 
always  the  terminal  guidance  subsystem  will  be  located  in  the  forward 
section.  However,  the  modularity  concept  used  in  this  study  allows 
both  kinds  of  exceptions.  An  exception  of  the  first  kind  is  to  allow  a 
section's  usual  role  to  change.  For  example,  the  forward  section, 
which  usually  contains  the  terminal  guidance  function,  may  sometimes 
contain  another  function  (e.g.  ,  midcourse  guidance  sensor).  An  excep¬ 
tion  of  the  second  kind  allows  a  particular  subsystem  to  be  located  in 
different  sections  in  different  configurations.  While  these  exceptions 
will  probably  be  rare,  they  are  admitted  to  the  modularity  concept  to 
allow  greater  flexibility.  The  spirit  of  modularity  demands  that  these 
exceptions  do  not  require  any  special  adjustments  or  parameter  settings 
in  the  assembly  process. 

6.1.2  Growth  Considerations 

It  is  desired  to  allow  additional  specific  subsystems  to  be  added  to 
the  weapon  system  (or  changes  made  to  an  existing  subsystem)  without 
extensive  rework  on  existing  equipment.  For  example,  suppose  that 
a  new  terminal  guidance  subsystem  is  added,  and  it  is  completely  con¬ 
tained  in  the  nose  section.  The  modularity  concept  requires  that  no 
changtfl  will  have  ta  b..  ii'^ade  in  iLe  SwClions;  this  includes  harness 

modifications . 

It  is  also  desired  that  field  retrofits  be  accomplished  with  a  niini- 
mum  of  rework  to  existing  sections.  Ideally,  a  new  box  replacing  an 
existing  box  in  an  existing  section  should  fit  in  the  same  physical  loca¬ 
tion  and  use  the  saiue  harness  termination  even  if  the  function  uf  the 
box  has  changed.  ^ 

The  modularity  concept  described  abbve  is  the  basis  for  defining 
the  integration  subsystem  of  which  the  digital  processor  is  a  part. 

6.2  THE  INTEGRATION  SUBSYSTEM 

The  integration  subsystem  for  a  fixed-design  weapon,  as  noted 
previously,  is  the  combination  of  the  digital  processor  and  a  harness 
with  dedicated  links  to  the  subsystem.  Thus,  each  subsystem  has  its 
own  dedicated  communication  link  with  the  processor.  On  this  link 
the  subsystem  can  request  data  from  the  processor  or  tell  the  processor 
that  it  has  data  ready.  This  capability  is  furnished  by  an  interrupt 
feature  in  the  processor.  The  interrupt  capability  must  be  vectored 
and  each  subsystem  requires  its  private  line.  Transmission  of  data 
from  a  subsystem  to  the  processor  requires  a  private  line  for  each 
discrete  and  a  serial  or  parallel  link  for  general  data.  Discretes  will 
in  tiu;  a  (flag  input),  Mof«^ 


data  transfer  is  via  some  kind  of  shared  memory.  Transmission  of 
data  from  the  processor  to  the  subsystem  is  by  the  same  means  (flags 
or  shared  memory). 

In  the  point  design,  the  physical  layout  can  be  adjusted  to  subsystem 
needs.  For  example,  if  one  of  these  dedicated  links  requires  a  path  for 
high  speed  parallel  data,  the  physical  arrangement  in  the  point  design 
can  be  adjusted  to  make  that  part  short.  In  general,  special  accommo¬ 
dations  can  be  made  for  each  path  to  account  for  peculiar  requirements 
of  the  subsystem. 

The  harness  concept  in  the  fixed-design  weapon  clearly  violates 
the  modularity  concept.  In  the  first  place,  the  dedicated  harness  does 
not  furnish  a  common  interface  at  the  section  level.  The  harness 
carries  only  the  lines  required  for  the  following  sections.  In  order  io 
provide  a  common  section  interface  with  this  type  of  harness,  all  lines 
for  all  functions  would  have  to  pass  through  all  sections.  This  bus 
structure  is  impractical  for  a  large  number  of  lines,  and  the  number 
will  be  larger,  particularly  when  growth  provision  is  included.  Further¬ 
more,  the  harness  provides  a  unique  interface  for  each  subsystem. 

This  situation  could  be  tolerated  for  a  given  generic  subsystem  in  a 
fixed  position.  In  this  case  each  species  of  the  subsystem  genus  could 
be  required  to  furnish  a  common  interface.  However,  since  in  this 
type  of  harness  each  wire  has  a  specific  meaning,  one  is  limited  in  the 
kinds  of  information  that  can  be  exchanged  with  the  subsystem.  This 
limits  growth.  Moreover,  in  the  modular  weapon  concept,  a  particular 
harness  link  terminus  does  not  always  attach  to  the  same  generic  sub¬ 
system,  In  the  dedicated  harness  concept,  extra  dedicated  links  would 
be  required  to  account  for  these  cases. 

For  the  above  reasons,  a  harness  with  dedicated  links  does  not 
appear  to  be  a  good  choice  for  the  modular  concept.  Some  type  of  bus 
is  required  to  give  the  common  interface  at  section  level  and  subsystem 
level.  To  limit  the  number  of  wires  in  the  bus,  it  should  be  time  shared 
among  the  subsystems  (i.  e.  ,  time  multiplexed).  Time  sharing  among 
the  subsystems  does  not  necessarily  require  a  common  format  for  data 
on  the  bus  as  long  as  there  is  a  way  of  identifying  data  source.  However, 
since  a  given  entry  point  on  the  bus  does  not  necessarily  correspond  to 
a  particular  generic  subsystem,  it  would  appear  that  a  common  format 
is  required. 

The  bus  structure  must  provide  all  the  functional  features  of  the 
dedicated  harness.  In  particular,  it  must  provide  a  high  enough  data 
rate  to  accommodate  the  bandwidth  of  all  required  data.  By  required 
data  is  meant  the  data  necessary  for  the  integration  function.  Also, 
the  bus  must  provide  an  interrupt  feature  to  allow  subsystems  to  signal 
the  processor  that  access  is  required.  The  bus  should  also  provide 
for  signaling  and  control  functions  (as  well  as  data)  from  the  processor 
to  the  subsystem.  Among  the  possible  formats  for  the  bus  are: 

1.  A  group  of  lines  on  which  analog  signals  may  be  placed 

2.  A  serial,  digital  format 


3.  A  parallel  digital  format 

Sunu  conibination  of  the  abo\’t^ 

f  Some  of  the  data  which  must  be  transferred  on  the  bus  require  a  preci- 

•  sion  greater  than  given  by  an  analog  system  (e,  g.  ,  inertial  reference 

I  data);  therefore,  it  is  necessary  that  the  bus  include  a  digital  format. 

I  Including  an  analog  format,  as  well,  would  allow  centralizing  the  analog- 

I  to-digital  and  digital-to-analog  conversion  for  some  of  the  signals, 

I  However,  transmission  of  analog  signals  over  a  long  bus  is  a  much 

:  more  difficult  process  than  for  digital  signals  because  of  voltage  offsets 

i  and  noise  pickup.  Therefore,  it  was  decided  to  limit  the  bus  to  a  digital 

format.  The  selection  of  a  serial  or  parallel  format  will  be  made  after 
f  a  discussion  of  the  functions  to  be  transmitted  on  the  bus. 

In  summary,  the  integration  subsystem  consists  of  the  digital 
processor  and  a  digital,  time-multiplexed  bus.  The  bus  traverses  each 
weapon  section  and  provides  a  common  interface  at  the  section  level. 
Interior  to  the  section,  bus  spurs  tap  off  from  the  bus  to  provide  a 
common  interface  at  the  subsystem  level.  It  should  be  noted  that  the 
interface  at  the  section  level  is  not  necessarily  the  same  as  the  interface 
at  the  subsystem  level.  In  other  words,  the  transmission  format  on  the 
bus  is  not  necessarily  the  same  format  as  presented  to  the  subsystem. 

The  bus  provides  interrupt  capability  as  well  as  data  transmission 
capability. 

6.3  PROCESSOR  FUNCTIONS  REQUIRED  FOR  INTEGRATION 

As  stated  before,  the  primary  function  of  the  digital  processing 
system  is  weapon  integration.  In  Section  V,  three  point  designs  were 
presented  in  which  the  processor  did  more  tasks  than  just  required  for 
integration.  In  fact,  one  of  the  objectives  of  that  exercise  was  to  maxi¬ 
mize  the  number  of  tasks  performed  by  the  processor.  At  this  point 
we  wish  to  determine  just  those  tasks  which  are  required  for  the  inte¬ 
gration  function.  It  is  these  tasks  which  will  be  the  basis  for  estimating 
the  required  processing  system  capabilities. 

6.  3.  1  System  Management  Functions 

The  system  management  functions  are  those  tasks  necessary  to 
combine  the  separate  subsystems  into  a  working  system.  In  the  fixed- 
designs  considered  earlier,  much  of  this  function  was  performed  by  the 
dedicated  harness  and  such  features  as  direct,  hardware,  vectored 
interrupt  in  the  processor.  These  features  do  not  exist  in  the  integra¬ 
tion  subsystem  described  in  subsection  6.2.  In  the  modular  weapon, 
the  system  management  tasks  are  software  controlled  and  performed 
by  the  digital  processor.  These  tasks  are  described  in  the  following 
paragraphs  by  a  step-by-step  analysis  of  what  the  processor  has  to  do 
for  this  integration  function. 

The  first  step  in  the  integration  process  is  for  the  processor  to 
determine  the  weapon  configuration.  In  order  to  do  this,  it  is  necessary 
that  each  subsystem  which  can  be  a  variable  in  a  configuration  identify 
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itself  to  the  processor.  This  requires  communication  over  the  bus. 

The  control  of  the  bus  comniunication  is  a  task  which  was  present  in 
only  rudimentary  form  in  the  fixed-design  weapon.  In  the  modular 
weapon,  with  the  time  multiplexed  bus,  it  is  a  much  more  significant 
function.  Thii  task  Is  also  assigned  to  fb*  p r‘-r*-j(*or.  The  subsystem 
identification  process,  incidentally,  places  a  definite  requirement  on 
each  subsystem  or  functional  module  to  provide  an  identifier  on  request. 

After  configuration  Identlfloalion,  the  proctssor  must  initiali2.o  tht 
system  by  setting  parameters  using  a  combination  of  pre-stored  data 
and  mission-related  data  from  the  avionics.  It  should  be  noted  that  the 
processor  consideis  the  iiitetfacfc  willi  the  aiTcralt  avionics  as  anethtr 
subsystem  as  far  as  the  above  tasks  are  concerned. 

After  initialization,  the  processor  exercises  control  over  the 
sequence  in  which  missile  tasks  are  performed  and  controls  the  required 
communication  on  the  bus.  This  is  a  real  time  control  function.  The 
throughput  of  the  combined  bus -processor  integration  subsystem  must 
bo  high  enough  to  satifcfy  any  pfapabMion  delay  re-juirements  of  the 
subsystem. 

The  weapon  may  also  have  to  go  through  a  self-test  sequence,  either 
while  on  the  aircraft  or  before  it  is  loaded  onto  the  aircraft.  The  self 
test  sequence  is  also  controlled  by  the  digital  processor. 

The  above-described  functions  are  called  system  management 
functions  and  are  a  necessary  part  of  integration.  They  are  listed  below. 

•  Configuration  Identification 

•  Communication  Control 

•  Initialization 

•  Sequencing 

•  Self-Test 

6.3.2  Flight  Control 

Another  function  which  is  closely  related  to  integration  is  the  flight 
control,  which  has  two  subfunctions:  stabilization  and  steering.  Stabili¬ 
zation,  from  the  viewpoint  of  a  digital  autopilot,  is  a  cascade  of  filters 
which  operate  on  inertial  sensor  data  to  form  flipper  commands  to 
stabilize  the  weapon  in  flight.  The  required  arrangement  of  the  filters 
is  a  function  of  the  aerodynamics.  The  flight  control  function  integrates 
the  proper  total  filter  function  from  available  modules  on  the  basis  of 
logic  signals  giving  the  status  of  missile  configuration. 

In  a  similar  sense  the  steering  part  of  the  flight  control  function 
synthesizes  the  proper  steering  commands  to  put  into  the  autopilot 
steering  loop  on  the  basis  of  the  missile  configuration  and  trajectory 
status . 

The  flight  control  function  is  thus  truly  a  weapon  integration  func¬ 
tion  in  the  modular  weapon. 
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6.  3.  3  Strapdown  Inertial  Reference 


There  is  one  more  function  which  should  be  analyzed  with  respect 
to  weapon  inttgration.  This  is  the  strapdown  inertial  reference  function 
(SIRF).  In  all  the  intended  uses  in  the  weapon  system  analyzed  in  this 
study,  the  SIRF  is  used  in  conjunction  with  another  subsystem  (a  mid¬ 
course  guidance  sensor)  which  provides  position  and/or  velocity  update 
information  for  the  SIRF.  There  are  several  different  update  subsystems 
(RaC,  GPS,  )  a. id  the  inforiiiatiOti  f  r uiii  each  is  filtered  differently 

for  use  in  the  SIRF.  Thus,  the  complete  SIRF,  including  the  proper  fil¬ 
tering  of  the  appropriate  update  data,  is  indeed  an  integration  function. 

6.  3.  4  CORE  Functions 

The  above  integration  functions.  System  Management ,  Flight  Control 
and  Strapdown  Inertial  Reference,  are  the  basic  functions  which  the 
digital  processor  must  perform.  These  CORE  functions  have  been  used 
to  set  the  requirements  for  the  DP  and  the  bus.  As  pointed  out  later, 
when  the  peak  throughput  requirements  for  the  CORE  functions,  includ¬ 
ing  propagation  delay  requirements,  are  satisfied,  the  digitalprocessor 
has  capacity  to  do  other,  lower  priority,  tasks  also.  The  tasks  which 
might  *H!  i.’'rluded  .iPe  tyjTcaUy  differtfil  in  differcTit  cuufiguratiuiio. 

Some  of  these  will  be  discussed  in  the  following  section. 

6.  3.  5  Bus  Transmission  Requirements  for  CORE  Functions 

At  this  point  we  are  in  a  position  to  make  a  tentative  decision  as 
to  whether  the  bus  should  be  a  serial  or  parallel  structure.  The  pro¬ 
cessing  and  bus  rate  requirements  for  the  system  management  func¬ 
tions  have  not  yet  been  derived;  however,  we  do  have  the  data  from 
the  three  fixed-point  designs.  The  required  bus  rates  for  these 
designs  is  shown  in  Table  13. 

The  highest  transmission  requirement  shown  in  the  table  is  about 
100  K  words  per  second  if  one  includes  the  requirements  for  both  data 
and  interrupts.  The  data  words  require  16  bits  for  data  and  perhaps 
4  bits  for  control  purposes.  Thus  the  required  bus  bit  rate  is  about 
2  million  bits  per  second.  This  rate  is  normally  considered  too  high 
to  support  with  a  shielded,  twisted  pair  bus  such  as  would  probably  be 
used  here.  However,  this  refers  to  buses  with  lengths  of  hundreds  of 
feet  or  more.  The  bus  in  the  modular  weapon  will  probably  not  exceed 
20  feet  in  length.  During  the  course  of  this  program,  transmission 
measurements  were  made  on  a  6  meter  bus  with  eight  terminals.  Trans¬ 
mission  rates  up  to  10  million  bits  per  second  were  achieved.  Thus, 
the  2  million  bits  per  second  should  not  present  any  problem. 


Now  the  data  in  the  table  refer  to  a  somewhat  different  case  than 
we  are  talking  about  for  integration.  The  Configuration  II  fixed-design 
included  the  flight  control  and  the  strapdown  inertial  reference  function, 
but  not  all  of  the  system  management  functions.  It  did  include,  how¬ 
ever,  line  and  field  processing  for  the  E-O  seeker  and  position  pro¬ 
cessing  for  the  LORAN  system.  The  E-O  processing  requires  higher 
bus  rates  than  estimated  for  the  system  management  function.  There¬ 
fore,  the  rates  required  for  Configuration  II  exceed  the  rates  required 
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TABLE  13.  BUS  TRANSMISSION  REQUIREMENTS  FOR  FIXED-DESIGN 

WEAPON  CONFIGURATIONS 


for  the  CORE  functions.  The  conclusion  is  that  a  serial  bus  is  adequate 
for  the  integration  subsystem.  This  conclusion  is  verified  in  the  next 
section  which  deals  with  system  design. 

6.4  CORE  DIGITAL  PROCESSING  SYSTEM 

The  overall  characteristics  of  the  integration  subsystem  for  the 
modular  weapon  were  determined  in  this  section.  This  subsystem  is 
called  the  digital  processing  system  for  the  CORE  (integration)  func¬ 
tions.  Figure  35  illustrates  the  system.  The  serial  digital  bus, 
called  the  weapon  bus,  provides  both  data  transmission  and  interrupt 
capability. 

This  bus  provides  a  flexible  communication  and  control  medium 
for  integration  of  the  weapon  subsystems.  The  standard  interface 
which  is  presented  to  all  subsystems  is  digital,  and  signal  conversion 
equipment  is  required  for  compatibility  with  existing  subsystems  as 
shown  in  the  figure.  All  data  transmissions  are  controlled  by  the  digi¬ 
tal  processor  software,  while  interrupt  transmissions  may  be  initiated 
by  any  subsystem.  The  CORE  functions  performed  in  the  digital  pro¬ 
cessor  are  System  Management,  Flight  Control,  and  Strapdown  Inertial 
Navigation. 


Figure  35.  Digital  Processing  System  Configuration 
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SECTION  VII 


DIGITAL  PROCESSING  SYSTEM  DESIGN 


Having  determined  the  broad  features  of  the  digital  processing 
system,  it  is  now  possible  to  proceed  with  a  more  detailed  definition 
and  to  derive  performance  requirements.  While  a  multiplexed  digital 
bus  has  been  specified,  the  bus  configuration  is  still  an  open  question 
and  tradeoff  studies  are  necessary  to  select  the  preferred  configuration. 
Likewise,  the  processor  configuration  has  not  yet  been  determined. 

In  this  section,  the  tradeoff  factors  pertinent  to  bus  and  processor 
configuration  are  examined  in  order  to  make  a  configuration  choice. 

With  the  overall  processing  configuration  in  hand,  it  is  possible  to 
proceed  to  a  definition  of  the  software  structure  which  will  support  the 
system  modularity  requirements,  and  then  to  specify  processor  archi¬ 
tecture  and  performance.  These  subjects  are  treated  in  the  following 
paragraphs. 

7.  1  WEAPON  BUS  DESIGN 

The  principal  tradeoff  areas  in  the  weapon  bus  design  are  the  bus 
topology  and  bus  control  methodology.  In  the  previous  section,  a  bit 
serial  digital  transmission  format  was  shown  to  be  compatible  with  the 
transmission  rate  requirements  of  the  weapon  system.  Bus  topology  is 
concerned  with  the  structure  of  the  weapon  harness  which  provides  all 
required  functional  interconnections  between  the  weapon  subsystems. 

Bus  control  is  concerned  with  the  resolution  of  bus  usage  conflicts 
in  the  real  time  operating  environment.  These  conflicts  arise  because 
of  the  asynchronous  nature  of  the  operations  of  the  weapon  subsystems, 
i.e.  ,  not  only  the  frequency  but  also  the  phasing  of  the  inte r subsystem 
communication  requirements  are  determined  by  each  subsystem. 

Two  general  types  of  inte rsubsystem  communication  and  control 
philosophies  can  be  considered  for  this  weapon  system.  The  first 
philosophy  would  require  each  subsystem  to  output  all  of  its  data  and 
status  information  each  time  it  is  updated  within  the  subsystem,  regard¬ 
less  of  whether  the  information  is  needed  by  the  other  weapon  sub¬ 
systems.  All  weapon  subsystems  would  examine  all  messages  and 
accept  the  parameters  which  it  needs  to  perform  its  functions.  There 
are  obvious  problems  with  this  philosophy.  First,  a  system  wide 
identifier  must  be  assigned  to  each  subsystem  parameter  to  facilitate 
the  decision  process  in  the  other  subsystems.  Second,  the  subsystems 
must  contain  decision  circuitry  and  identifier  storage  for  all  pertinent 
input  parameters.  The  bus  capacity  must  be  sufficient  to  allow  for 
both  required  and  useless  parameter  transmission.  A  final  problem 
with  this  philosophy  is  that  data  consistency  cannot  be  guaranteed. 

Since  each  subsystem  outputs  its  data  asynchronously  when  ready,  the 
data  in  the  user  subsystem  may  be  only  partially  updated  when  needed  by 
the  user.  This  philosophy  leads  to  implementation  complexity  which  is 
undesirable. 


A  second  philosophy  implies  that  only  pertinent  parameters  are 
output  by  each  weapon  subsystem  in  response  to  the  requirements  of 
the  other  weapon  subsystenis.  This  type  of  eystetn  coinmunicati jr 
control  requires  che  transmission  of  words  indicating  both  the  need  for 
data  and  what  data  are  required.  This  is  the  function  of  the  interrupt 
words  discussed  in  the  previous  section.  The  total  bus  traffic  is 
obviously  lower  in  this  case  since  only  required  parameters  are  trans¬ 
ferred  between  the  weapon  subsystems.  However,  the  problem  asso¬ 
ciated  with  system-wide  identification  of  both  subsystem  parameters 
and  interrupts  still  exist.  This  problem  will  be  addressed  in  subse¬ 
quent  paragraphs  of  this  section. 

Weapon  configuration  information  is  contained  in  the  digital  proces¬ 
sor  software  which  can  be  used  to  determine  the  required  intersubsystem 
communication  for  the  weapon.  Tw’o  real  time  bus  control  philosophies 
may  be  considered;  central  and  distributed.  The  distributed  control 
philosophy  requires  that  weapon  configuration  information  be  sent  to 
each  subsystem  to  minimize  the  complexity  of  the  bus  control  circuitry 
in  the  subsystem.  Central  control  by  the  digital  processor  allows  min¬ 
imum  complexity  in  each  subsystem.  The  applicability  of  these  control 
philosophies  is  presented  for  different  bus  topologies  in  the  following 
paragraphs. 

7.  1.  1  Bus  Topology  and  Control  Structure 

Ideally,  the  bus  topology  should  allow  modular  addition  or  deletion 
of  subsystems  within  a  weapon  section  without  modification  of  the 
weapon  harness  associated  with  the  bus.  There  are  two  topologies 
which  provide  this  simplicity  in  weapon  assembly.  These  are  the  ring 
and  serial  structures  shown  in  Figure  36.  Both  structures  can  provide 
the  required  intersubsystem  communications,  but  their  implications 
on  subsystem  requirements  must  be  determined.  Other  topologies  such 
as  the  star,  fully  connected,  and  tree  structures  require  that  new  signal 
paths  be  added  to  the  existing  structure  whenever  a  new  module  is  added. 

Ring  Structure 


The  ring  structure  utilizes  a  distributed  control  philosophy  and 
allows  each  subsystem  to  output  both  data  and  control  parameters,  and 
interrupt  words  asynchronously  on  the  data  bus.  The  ring  operates  by 
transmitting  a  message  word  from  one  unit  to  the  next  in  sequence 
around  the  ring.  A  given  station  can  transmit  a  word  only  to  a  station 
adjacent  to  it  and  on  its  right  hand  side.  Each  word  must  carry  an 
address  identifying  its  destination.  If  a  station  receives  a  word  that  is 
not  addressed  to  it,  it  transmits  the  word  in  the  ring  at  the  next  word 
time.  If  there  are  N  stations  on  the  ring,  there  can  be  as  many  as  N 
words  being  transmitted  at  a  time,  but  it  may  take  N-1  word  times  for 
a  message  to  get  from  its  source  to  its  destination.  The  control  of  the 
ring  structure  is  relatively  simple  since  any  subsystem  can  put  a  mes¬ 
sage  word  on  the  bus  when  it  detects  an  empty  word  slot  in  the  ring. 
This  provides  good  time  response  in  an  asynchronous  operating 
environment  provided  that  empty  slots  are  available.  However,  the 
timely  existence  of  empty  slots  in  the  structure  cannot  be  guaranteed 


Figure  36.  Weapon  Bus  Topology 


for  time  critical  parameters  in  all  weapon  configurations.  The  total 
bus  transmission  delay  also  depends  on  the  number  of  subsystems  in 
the  weapon  configuration  between  the  source  and  destination  of  the 
transfer. 

Empty  slots  can  be  created  for  time -critical  parameters  by 
removing  other  data  from  the  ring,  storing  the  data,  and  then  putting 
it  back  on  the  bus  after  the  critical  parameters  have  been  transferred. 
However,  this  implies  that  sources  of  time -c ritical  data  must  be 
capable  of  assessing  the  priority  of  their  data  relative  to  other  data  in 
the  system.  This  requirement  introduces  complexity  into  the  component 
subsystems. 

The  priority  problem  could  be  solved  also  by  providing  sufficient 
bus  capacity  to  transfer  time -critical  data  in  the  worst  case  operating 
environment.  However,  it  is  nearly  impossible  to  identify  a  worst  case 
environment  within  the  current  weapon  system  definition,  without  con¬ 
sidering  the  addition  of  subsystems  in  the  future.  In  addition,  each 
word  transferred  must  have  a  companion  acknowledge  word  from  the 
destination  to  indicate  correct  reception  of  the  word,  which  reduces  the 
actual  bus  capacity  by  50  percent.  Each  source  subsystem  must  store 
all  output  data  until  the  appropriate  acknowledge  is  received  to  allow 
retransmission  in  case  of  error.  As  noted  before,  each  word  on  the 
bus  must  contain  the  destination.  In  addition,  the  data  must  be  identi¬ 
fied  in  the  word  to  determine  its  use  in  the  destination  subsystem.  The 
requirement  for  both  a  destination  address  and  data  identifier  in  each 
word  results  in  a  large  number  of  bits  in  each  message  word  relative 


to  the  data  content  of  the  word.  This  type  of  overhead  is  present  for 
every  word  of  a  block  transmission  since  consecutive  transmission  of 
the  words  in  a  block  transfer  cannot  be  guaranteed  in  the  ring  structure. 
Message  word  format  will  be  discussed  in  a  later  paragraph. 

Serial  Structure 

The  serial  structure  operates  by  having  all  stations  on  the  bus 
simultaneously  receive  the  transmitted  message.  Each  staiion  must 
riimidc  for  itself  u  hethe  r  or  not  the  received  tr  ansmioisiuii  ia  foi  it. 

Only  one  word  may  be  in  transit  at  a  time,  but  a  word  may  be  sent  from 
any  source  to  any  destination  in  a  single  word  time.  Correct  reception 
of  a  word  iH  fTsily  aekirtjwlc  dg..  J  since  it  p^rtai.xo  lu  tiie  laSL  wuid 
transferred  on  the  bus. 

The  control  of  the  serial  structure  is  more  complex  than  for  the 
ring  structure,  hut  the  sanit?  factors  discussed  previously  fur  tiie  ring 
structure  also  apply  to  the  serial  structure.  The  control  problem  has 
two  parts;  determination  of  whether  the  bus  is  in  use,  and  resolving 
priority  conflicts  in  putting  messages  on  the  bus.  Three  candidate  con¬ 
trol  structures  were  investigated  for  the  serial  bus;  rotating  window, 
bus  race,  and  central  control.  Both  the  bus  race  and  rotating  window 
struciuj'f'ft  uruvide  diilribult  J  Ft  il  tiiiie  ec-nrrol  of  ilit  Lus.  These 
structures  provide  for  transmission  of  data  and  control  parameters, 
as  well  as  interrupts  on  the  date  bus. 

The  rotating  wir.duw  Structure  shonn  in  Figure  37  is  very  sitidlar 
to  the  ring  structure  previously  discussed  in  that  permission  to  put 
messages  on  the  bus  is  passed  from  one  subsystem  (DE)  to  the  next  in 
sequence.  In  fact,  if  the  window  is  only  one  message  word  long,  the 
serial  structure  essentially  degenerates  to  the  ring  structure  except 
for  allowing  messages  to  be  transferred  between  any  two  subsystems 
in  one  word  time.  If  the  window  may  be  retained  by  a  DE  until  all  words 
of  a  block  transmission  are  transferred,  some  increase  in  bus  efficiency 
is  allowed  by  appropriately  formatting  the  message  words.  However, 
this  philosophy  would  allow  a  low  priority  block  transmission  to  prevent 
transfer  of  time -c ritical  data  by  another  DE.  Since  this  control  tech¬ 
nique  does  not  allow  priority  assignment  for  bus  messages,  it  is  not 
recommended. 

The  bus  race  control  structure  is  shown  in  Figure  38.  The  bus 
race  structure  operates  by  connecting  the  DEs  with  a  single  control 
line  labeled  the  message  in  progress  (mip)  line.  Whenever  a  DE  is 
transmitting  a  message,  it  also  places  a  level  on  the  mip  line.  Before 
starting  a  transmission  a  DE  will  inspect  the  mip  line  to  assure  itself 
that  the  bus  is  not  in  use.  If  the  bus  is  in  use,  the  DE  wishing  to  make 
a  transmission  will  monitor  the  mip  line  until  the  level  disappears.  It 
will  then  raise  the  mip  line  itself  and  begin  transmitting. 

A  probkni  ari-KOFJ  whvn  two  DEs  wish  a  tr&usuiission 

simultaneously.  Following  the  procedure  just  outlined,  both  units 
would  wait  for  the  mip  level  to  disappear  and  then  both  would  race  for 
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Figure  37.  Rotating  Window  Control  Structure 
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Figure  38,  Bus  Race  Control  Structure 


the  bus.  The  outcome  of  the  race  would  probably  be  that  both  units 
would  think  they'd  won  and  start  transmitting  simultaneously.  This 
would  result  in  erroneous  transmissions  on  the  bus. 


To  avoid  this  problem,  a  slight  modification  is  required.  Each 
unit  is  assigned  a  fixed  wait  period.  When  a  DE  wants  to  transmit,  it 
first  raises  the  mip  line,  waits  its  assigned  period  and  then  momen¬ 
tarily  lowers  the  mip  level.  If  the  mip  remains  high,  it  indicates  to 
the  inquiring  DE  that  some  other  DE  is  also  trying  to  transmit  and  the 
bus  race  has  been  lost.  The  DE  that  just  looked  must  now  go  back  and 
wait  for  the  new  transmission  to  be  completed.  Clearly  this  system 
assigns  an  implicit  priority  in  that  the  longer  the  assigned  wait  period, 
the  higher  the  priority. 


This  structure  can  be  used  either  for  single  word  or  block  data 
transmissions.  If  the  mip  line  is  lowered  after  each  word  of  block 
transmission,  time  response  to  critical  data  is  improved,  but  bus 
transfer  efficiency  is  reduced  by  the  waiting  period  to  resolve  the  bus 
race  for  each  word.  Also,  each  word  must  contain  both  destination 
address  and  data  identifier  in  this  case.  If  the  mip  line  is  only  lowered 


at  the  end  of  a  block  data  transmission,  time  critical  data  response  may 
not  be  adequate,  since  the  subsystems  operate  asynchronously. 

Another  potential  problem  is  the  implicit  priority  assignment, 
which  must  be  made  on  a  configuration-wide  basis.  The  digital  proces¬ 
sor  can  output  priority  data  for  each  DE  as  part  of  the  prelaunch  prep¬ 
aration  of  the  weapon.  However,  some  subsystems  output  more  than 
one  type  of  data,  and  the  priority  of  each  type  may  vary.  This  structure 
can  theoretically  accommodate  varying  priorities  for  a  single  DE,  but 
the  control  structure  will  be  complicated. 

The  central  control  structure  usually  uses  an  auxiliary  communi¬ 
cation  structure  for  communication  of  each  DE  with  the  bus  controller, 
as  shown  in  Figure  39.  When  a  DE  wishes  to  use  the  bus,  it  informs 
che  bus  controller  which  allocates  the  bus  on  the  basis  of  the  system 
state  which  includes  all  current  and  pending  requests  from  DEs,  The 
requests  from  the  DEs  to  the  controller  furnish  data  available /data 
required  types  of  information  in  accordance  to  the  asynchronous  oper¬ 
ations  of  the  weapon  subsystems.  This  function  was  performed  by  the 
interrupt  inputs  of  the  three  point  designs.  Alternatively,  the  central 
bus  controller  may  operate  without  the  auxiliary  structure  by  using  a 
polling  procedure.  This  procedure  would  require  that  the  controller 
sequentially  request  status  (interrupt)  information  via  the  data  bus 
from  each  subsystem  and  perform  a  bus  allocation  on  this  basis.  The 
bus  response  to  interrupts  with  this  form  of  central  control  is  equiv¬ 
alent  to  that  of  the  rotating  wdndow  control  structure  with  a  window 
time  corresponding  to  two  message  word  times  (request,  response)  for 
each  subsystem  in  the  weapon.  An  extremely  high  Ijus  capacity  would 
be  required  to  meet  the  response  time  requirements  for  time  critical 
data  transfers,  especially  since  the  polling  procedure  must  be  per- 
fuPiiieJ  at  a  fixed  rate  indtpendent  uf  dal  a  dilxj  WiAtX  i  i  O-IlO  fora  uC  e  apy - 

ing  the  bus. 

The  obvious  alternative  to  a  polling  procedure  is  the  addition  of  a 
second  bus  to  allow  asynchronous  interrupt  transfers  between  the 
weapon  subsystems  and  the  central  controller.  ihe  requirement  for 
asynchronous  operation  of  this  interrupt  bus  dictates  a  distributed  con¬ 
trol  philosophy.  Of  the  distributed  control  structures,  the  bus  race 


Figure  39.  Central  Control  Structure 
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control  provides  the  best  time  response.  Since  interrupt  data  can  be 
transferred  in  a  single  word,  and  the  interrupt  traffic  is  relatively  low, 
the  problems  associated  with  bus  race  control  of  the  data  bus  are 
essentially  eliminated. 

The  use  cf  a  separate  interrupt  bus  to  transfer  data  requests 
between  the  weapon  subsystems  and  the  central  data  bus  controller  is 
considered  a  necessary  adjunct  to  central  control.  In  order  for  the 
I  central  controller  to  perform  its  function,  it  must  send  control  w’ords 

to  the  source  and  destination  subsystems.  These  words  both  set  the 
f  .  subsystem  data  transfer  mode  (transmit,  receive)  and  identify  the  data 

being  t  ransCi' rredr  C4.’nfr3l  ’■jus  ct-rU  rcJLe r  liAPdwirei  rompk: itity  is  min¬ 
imized  by  performing  the  dynamic  allocation  in  the  DP  software.  The 
interpretation  of  interrupt  signals  is  an  integral  part  of  this  function. 

7.  1.  2  Bus  Message  Word  Length 

i 

The  bus  message  word  length  is  determined  both  by  the  information 
which  must  be  transferred  in  each  message  word  and  the  coding  tech¬ 
nique  used  in  the  word.  Generic  ally,  the  inforn'.ation  content  of  the 
message  word  can  be  divided  into  three  fields;  data,  identification,  and 
error  detection.  The  data  field  contains  information  in  a  form  useful 
within  the  destination  subsystem  and  includes  data,  subsystem  status 
and  control  parameters,  and  coded  interrupt  commands.  A  data  field 
of  I6  bits  has  been  used  for  compatibility  with  DP  word  size.  The 
identification  category  includes  source  and  destination  subsystem 
information  as  required  by  the  bus  control  elements  and  indicates  the 
purpose  of  the  word  data  content  within  the  destination  subsystem.  The 
error  detection  category  contains  one  or  more  parity  bits  as  required 
to  meet  the  transfer  reliability  specification.  The  coding  problem  is 
associated  with  the  identification  category  in  which  maximum  informa¬ 
tion  capacity  is  desired  to  insure  compatibility  with  total  weapon  system 
requirements.  Conversely,  the  coding  should  allow  minimum  complex¬ 
ity  in  thv  iRtt-rfacf  circiiirry  ti  tbs  bu»  and  carh  subfiystum^  In 

the  following  discussion,  this  interface  circuitry  is  designated  as  a  bus 
interface  unit  (BIU)  and  includes  all  necessary  bus  control  elements. 

Message  Identification  Coding 

Three  coding  techniques  for  the  message  identification  information 
are  shewn  in  Figure  40«  The  weapon  configuration  information  required 
in  the  combination  of  BIU  and  subsystem  varies  with  coding  technique. 

If  a  system-level  identifier  is  used  to  define  the  data  content  of  each 
message  word  (or  block  of  words  for  block  transmission  formats),  no 
weapon  configuration  information  is  required  in  either  the  BIU  or  sub¬ 
system.  System  level  identification  implies  that  any  source  subsystem 
may  output  each  of  its  message  words  with  an  identifier  which  is  only 
a  function  of  the  data  content  and  completely  independent  of  the  destina¬ 
tion.  Furthermore,  the  destination  subsystem  operations  on  the  mes¬ 
sage  data  content  are  completely  determined  by  the  identifier.  If  the 
operations  of  the  destination  subsystem  depend  on  which  of  the  alterna¬ 
tive  subsysleiii  s  jurcea  if  a  si-«cllic  parar/.ete  r  «luaUy  IurniBh«d  Ihe 


Figure  40.  Message  Identification  Coding 


data,  a  different  identifier  must  be  assigned  to  the  parameter  for  each 
source.  This  implies  that  the  identifier  may  be  divided  into  two  fields; 
source  identification,  and  parameter  identification.  In  the  most  gen¬ 
eral  case,  this  format  is  required  and  results  in  a  large  number  of 
bits  in  the  message  to  allow  for  specification  of  all  possible  types  of 
data,  control  signals,  and  interrupts  on  a  system  wide  basis.  Each 
subsystem  must  compare  the  identifier  of  each  message  word  on  the 
bus  to  all  identifiers  pertinent  to  the  subsystem.  When  a  word  is 
accepted,  the  identifier  must  be  interpreted  by  the  subsystem--  this 
mapping  from  message  identifier  space  to  subsystem  operation  space 
is  non-trivial.  The  subsystem  must  also  store  identifiers  for  each  of 
its  pertinent  bus  message  outputs.  This  identification  coding  technique 
can  involve  considerable  subsystem  complexity  and  should  only  be  con¬ 
sidered  for  distributed  bus  control  techniques. 

The  second  and  third  coding  techniques  both  use  two  fields  to  facil¬ 
itate  the  decision  process  in  the  combination  of  BIU  and  subsystem. 
Either  technique  may  be  used  for  both  central  and  distributed  control 
philosophy.  The  first  field  of  both  techniques  identifies  the  destination 
of  the  message,  and  implies  that  weapon  configuration  information 
must  be  contained  in  the  bus  control  element  which  causes  the  message 
word  to  be  sent.  The  only  difference  between  the  two  techniques  is  the 
coding  of  the  destination;  subsystem  versus  BIU.  Since  only  the  DP  has 
complete  weapon  configuration  information,  a  distributed  control 
philosophy  would  require  that  the  DP  furnish  destination  information  to 
each  message  source  for  each  type  of  message  output  in  the  most  gen¬ 
eral  case.  However,  in  any  weapon  configuration,  all  bus  communica¬ 
tion  is  between  the  DP  and  the  other  weapon  subsystems.  Direct  com¬ 
munication  between  the  other  subsystems  is  generally  not  required, 
and,  if  desired,  usually  involves  conditioning  of  the  parameters  which 
is  a  DP  function.  Thus,  any  distributed  element  need  only  insert  a 
destination  identifier  corresponding  to  the  DP  if  distributed  bus  control 
is  used.  The  DP  contains  all  configuration  information  required  to 
determine  the  appropriate  destination  for  any  message  which  it 
originate  s . 


70 


The  tradeoff  to  determine  the  coding  of  the  destination  identifier 
favors  the  BIU  number  rather  than  subsystem  number  for  the  following 
reasons.  If  a  number  is  assigned  to  each  BIU  independent  of  the  sub¬ 
system  to  which  it  is  connected,  the  destination  ID  field  need  only 
account  for  the  maximum  number  of  subsystems  in  any  single  weapon 
configuration  (estimated  as  16)  rather  than  the  total  number  of  sub¬ 
systems  in  the  weapon  system.  In  order  for  the  DP  to  identify  the 
weapon  configuration,  it  must  access  the  subsystem  identifiers.  This 
process  is  simplified  by  the  BIU  coding,  since  the  subsystem  identifier 
iran  ’if]  an  addressable  output  of  each  subsystem  via  its  BIU  and  the  DP 
need  only  access  all  BIUs  to  obtain  the  subsystem  identifiers. 

The  coding  of  the  parameter  ID  field  must  allow  all  parameters 
input  to  the  DP  in  any  weapon  configuration  to  be  uniquely  identified, 
since  the  number  of  parameters  between  tne  DP  and  any  single  w’eapon 
subsystem  is  small.  In  lieu  of  making  a  detailed  study  of  all  possible 
coding  schemes  for  parameter  identification,  a  12  bit  field  corres  ¬ 
ponding  to  the  maximum  expected  DP  read/write  operand  memory 
space  has  been  assumed.  This  allows  simple  allocation  of  blocks  of 
memory  for  alternative  subsystems  of  each  type  for  the  distributed  bus 
control  techniques.  Each  subsystem  output  parameter  can  then  be 
assigned  a  fixed  address  which  is  stored  within  the  subsystem  and 
accessed  by  the  bus  controller  as  part  of  the  message  word.  A  smaller 
address  space  is  allowable  for  central  bus  control,  since  the  DP  can 
dynamically  allocate  its  memory  for  each  configuration.  However,  all 
message  Wof  ls  on  the  data  bus  must  be  the  ■san.e  length  fur  siiiiplicity 
of  implementation  in  the  bus  controller. 

Bus  Message  Formats 


The  bets  tiiessige  "woid  cuTileTils  applicable  to  the  various  bus  top¬ 
ologies  for  both  single  word  and  block  data  transmissions  are  shown  in 
Figure  41.  The  number  of  bits  shown  for  each  field  are  based  on  the 
coding  philosophy  presented  in  the  previous  paragraph.  Small  varia¬ 
tions  in  these  numbers  will  not  have  any  significant  effect  on  the  bus 
design  tradeoffs.  The  ordering  of  the  information  within  the  word  is 
arbitrary  and  may  be  adjusted  for  minimum  hardware  implementation. 

Analysis  of  these  word  formats  and  bus  operating  procedures 
results  in  the  bus  transfer  efficiencies  shown  in  Table  14.  These 
results  are  normalized  to  an  N  word  block  data  transfer  since  the 
majority  of  the  data  sources  provide  more  than  one  word  at  their  trans¬ 
fer  rate  Tnbie  1?>,  Thi]  JlpfUl  struci-ures  obviously  are  more 

efficient  than  the  ring  structure  and  the  block  format  for  the  serial 
structures  is  more  efficient  than  the  single  w'ord  format. 

As  discussed  previously,  interrupts  must  be  transfe rred  to  synthro- 
nize  the  subsystem  operations.  The  seriai/bus  race  design  can  also 
transfer  coded  interrupt  data  at  a  cost  of  40  bits  for  each  command.  A 
separate  interrupt  bus  is  liSed  £ox  the  se  r  ial/ ctnli  al  cuntlol  design  and 
the  interrupt  word  format  is  shown  in  Figure  42  (13  bits). 
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TABLE  14.  BUS  TRANSFER  EFFICIENCY 


BUS  TOPOLOG  V/CONTROL 


TOTAL  BITS  FOR  16N  DATA  BITS 


RING  STRUCTURE 


p 

OP  CODE 

ID 

(3) 

SOURCE 

(4) 


DESTINATION 

(4) 


DATA  ADDRESS 
112) 


SINGLE  WORD,  BUS  RACE 


SERIAL  STRUCTURE 


P  OP  CODE 
(1)  (1) 


DESTINATION 

(4) 


DATA  ADDRESS 
(12) 


BLOCK  TRANSFER 


CONTROL 


P 

OP  CODE 

ID 

13) 

DESTINATION 

(4) 


DATA  ADDRESS 
112) 


1/BLOCK:BUSRACE 

2/BLOCK:CEN7RAL 


□ATA  ^  OP  CODE 
(1)  (3) 


Figure  41,  Bus  Message  Formats 
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DESTINATION 

14) 


INTERRUPT  ID 
18) 


Figure  42.  Interrupt  Bus  Word  Format 


7.  1.  3  Weapon  Bus  Tradeoff  Summary 


The  ring  structure  is  not  recommended  because  of  long  transfer 
times  for  critical  data  and  low  bus  transfer  efficiency.  The  serial/bus 
race  design  with  block  transfer  format  has  the  highest  transfer  effi¬ 
ciency,  but  potentially  cannot  mtet  the  time  requirements  for  critical 
data  since  a  low  priority  bioc^  transfer  from  one  subsystem  cannot  be 
interrupted  for  a  high  priority  transfer  for  a  different  subsystem. 

Only  the  serial/central  control  design  provides  a  system-wide  bus 
allocation  capability,  but  a  separate  interrupt  bus  is  required.  The 
serial  bus  structure  with  the  central  controller  installed  in  the  digital 
processor  is  the  recommended  design  for  the  data  bus.  This  design 
provides  good  transfer  efficiency  for  data  blocks,  and  the  system  state 
data  required  for  bus  allocation  is  contained  in  the  digital  processor 
software.  The  central  controller  hardware  complexity  is  minimized  by 
-making  the  allocation  decisions  in  the  software.  This  allows  a  hardware 
implementation  of  the  central  controller  which  is  independent  of  weapon 
configuration. 

Central  control  of  the  interrupt  bus  is  not  recommended  since 
interrupt  generation  by  the  weapon  subsystems  is  asynchronous.  Since 
interrupt  data  can  be  transferred  in  a  single  word,  bus  race  control  of 
the  interrupt  bus  is  recommended.  Priority  can  be  set  for  each  sub¬ 
system  via  the  data  bus  as  part  of  the  prelaunch  weapon  preparation  on 
die  basis  of  interrupt  rate,  this  technique  provides  short  wait  times 
for  critical  interrupt  transfers. 

7.  2  PROCESSOR  SYSTEM  ARCHITECTURE 

In  the  preceding  subsection,  a  weapon  bus  configuration  was  chosen 
for  the  modular  weapon.  In  this  subsection  another  aspect  of  system 
architecture  is  examined,  i.  e.  ,  processor  system  architecture.  The 
requirements  for  the  digital  processor  are  based  upon  the  CORE 
function;  System  Management,  Flight  Control  and  Strapdown  Inertial 
Reference  Function.  The  question  of  interest  here  is,  should  these 
functions  all  be  performed  in  a  single  processor  or  should  they  be  dis¬ 
tributed  among  two  or  more  processors. 

In  the  analysis  reported  below,  it  has  been  assumed  that  the  system 
•-nanagfimcnt  function  would  not  he  split  up.  That  is,  basic  integration 
and  control  function  should  reside  in  a  single  processor.  Therefore, 
the  tradeoff  areas  are  concerned  with  performing  the  flight  control 
function  and  the  strapdown  inertial  reference  function  in  separate 
processors.  It  was  not  the  purpose  of  the  analysis  to  create  new  sub¬ 
system  designs;  the  analysis  is  based  on  existing  designs.  Specifically, 
the  <^light  control  subsystem  used  in  the  auadyais  1»  LjuUrc!  OH  riw  GBT'-ifi 
flight  control. 

The  processor  system  architecture  analysis  is  concerned  with  the 
effect  on  total  processing  requirements  of  distributing  the  CORE  func¬ 
tions  among  an  arbitrary  number  of  processing  elements.  For  this 


^  are*i-.^^WB9SWPftr»S^'  ^Er6>  -.  ... 


.■feU.l:.li!,iJ4-.HW-^J 


»  .  •,,-  _ nfJH^nasa.^- 


study,  3  disfihiif-pd  architecture  is  defined  as  a  number  of  processing 
elements  interconnected  via  the  weapon  bus.  These  processing  ele¬ 
ments  may  be  collocated  with  other  weapon  subsystems  and  provide  an 
adapter  module  function  for  a  subsystem,  but  are  not  necessarily  ded¬ 
icated  to  the  processing  functions  associated  with  the  subsystem.  Any 
digital  processing  element  physically  located  within  a  weapon  subsystem 
and  totally  dedicated  to  functions  of  the  subsystem  is  not  part  of  the 
digital  processor  architecture.  The  central  processor  architecture  is 
a  special  case  within  this  definition  of  a  distributed  processing 
architecture. 


In  order  to  perform  any  function  in  any  of  the  digital  processing 
elements,  the  generic  procedure  shown  in  Figure  43  is  followed.  Some 
of  the  steps  shown  are  trivial  when  the  input  data  source  and  output 
data  sink  are  within  one  digital  processing  element.  If  the  data  source 
and/or  sink  are  in  different  physical  locations,  the  data  transfers  are 
weapon  bus  operations.  The  steps  shown  in  this  figure  do  not  include 
the  weapon  integration  process  in  which  the  required  processing  func¬ 
tions  and  data  sources  and  sinks  are  identified  for  the  weapon  config¬ 
uration.  The  executive  software  operations  discussed  in  the  following 
section  are  required  to  energize  the  function  processing  and  interface 
with  the  weapon  bus,  and  are  implicit  requirements. 


The  entire  System  Management  function  should  be  performed  in  a 
single  processing  element  wh’ch  also  includes  the  weapon  data  bus  con¬ 
troller,  This  processing  element  is  designated  as  the  control  proces¬ 
sor  (CP)  since  it  not  only  controls  the  other  elements  of  the  distributed 
processor,  but  also  the  other  weapon  subsystems.  The  CP  must  con¬ 
tain  the  complete  executive  software  structure  described  in  the  follow¬ 
ing  section  to  support  the  integration  functions.  The  degree  to  which 
this  executive  software  must  be  duplicated  in  the  other  distributed 
processing  elements  depends  on  the  partitioning  of  the  remaining 
functions. 


7.  2.  1  Flight  Control  Function  in  Separate  Processor 


From  previous  experience  with  the  GBU-15  autopilot,  it  is  known 
that  there  i  re  two  factors  which  determine  processor  throughput 
requirements.  These  are  the  computational  task  itself  and  the  propa¬ 
gation  delay  requirements  to  preserve  stability.  Of  particular  interest 

in  the  analysis  is  the  effect  of  the  weapon  bus  on  the  propagation  delay 
requirement  (the  GBU-15  does  not  have  a  multiplexed  bus). 


The  processor  which  performs  the  flight  control  function  is  desig¬ 
nated  as  a  flight  control  processor  (FCP).  The  operations  required  by 
the  CP  to  support  the  FCP  are  dependent  on  both  the  technique  used  to 
interconnect  the  flight  control  sensors  and  actuators  with  the  FCP 
(weapon  bus  versus  direct  I/O)  and  the  method  of  real  time  control  of 
the  FCP  functions.  These  factors  are  not  independent  and  are  discussed 
in  the  following  paragraphs  for  the  configuration  examples  shown  in 
Figure  44.  The  only  assumption  made  on  the  physical  location  of  the 
elements  shown  in  the  figure  is  that  direct  I/O  connection  is  only  allowed 
if  the  elements  are  located  in  the  same  weapon  section. 
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Figure  43,  Processing  Sequence 
for  Digital  Functions 


CONFIGURATION 

c 


FCP  INTERCONNECTION 
SENSORS  ACTUATORS 


WEAPON  BUS  WEAPON  BUS 


Figure  44,  Distributed  Processing  Configuration  Examples 

Flight  Control  Functions 


The  following  assumptions  have  been  made  concerning  the  flight 
control  function: 

1.  Both  the  stabilization  and  steering  functions  are  performed  at 

a  fixed  iteration  rate.  If  the  iteration  rates  vary  with  airframe,  the  CP 
determines  the  appropriate  rate  for  each  weapon  configuration. 

2.  Th»^  inertial  sensor  output  data  format  may  be  either  digital 
or  analog.  In  either  case,  a  sample  command  at  the  appropriate  iter¬ 
ation  rate  is  required  to  initiate  the  formatting  of  the  sensor  data  for 
use  in  the  FCP.  This  command  is  generated  by  the  real  time  control 
aiemctu  (Cr  uT  rCT’)  and  fhv  re»pon*e  Mr.t-e  of  njnsoj  arid  funnattiiig 
circuitry  may  vary  with  sensor  subsystem.  Sampling  and  format  con¬ 
version  is  a  function  of  the  sensor  subsystem. 

3.  The  actuator  subsystem  may  be  analog  requiring  format  con¬ 
version  of  the  FCP  digital  output  data.  This  conversion,  if  required, 
is  performed  by  the  actuator  subsystem. 

The  sequence  of  operations  involved  in  each  of  the  flight  control 
functions  (stabilization  and  steering)  are  shown  functionally  in  Fig¬ 
ure  45.  These  operation  sequences  must  be  partitioned  between  the 
CP  and  FCP  and  the  performance  requirements  on  the  elements  of  the 
distributed  processing  system  (CP,  FCP,  and  weapon  bus)  must  be 
determined  for  each  of  the  configuration  examples. 

The  principal  processing  element  requirements  of  interest  are 
throughput  rate  and  memory  capacity.  The  interaction  of  processor 
throughput  and  weapon  bus  capacity  must  also  be  determined.  The 
following  assumptions  have  been  made  in  the  study: 

1.  The  CP  and  FCP  have  identical  processing  capability  (through¬ 
put,  instruction  set), 

2.  The  CP  and  FCP  both  contain  the  executive  software,  with  the 
exception  of  the  bus  control  function  which  is  only  installed  in  the  CP. 

3.  All  system  level  timing  is  controlled  by  the  CP.  This  implies 
that  appropriate  interrupts  are  sent  from  the  CP  to  the  other  elements 
to  synchronize  their  operations. 

4.  The  stabilization  function  propagation  delay  requirement  is 
600  microseconds  (GEtJ-15  requirement)  to  complete  all  operations 
from  sensor  output  sampling  through  conversion  of  the  actuator 
commands. 

5.  Sensor  output  data  formatting  requires  20  microseconds  per 
data  word  (set  by  analog- digital  conversion). 

6.  Sensor  data  transfers  to  the  FCP  will  be  in  block  format  for 
Configurations  B  and  C  under  control  of  the  CP  in  response  to  an  inter¬ 
rupt  from  the  sensors  when  all  data  has  been  formatted. 


7.  Digital-analog  conversion  of  the  actuator  commands  requires 
5  microseconds  per  data  word. 


8.  The  system  control  procedure  used  for  the  analysis  is  based 
upon  the  bus  control  philosophy  developed  in  the  preceding  section. 
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Figure  45,  Flight  Control  Function  Sequences 


The  instructions  executed  for  each  software  control  function  are 
shown  in  Table  15.  These  are  in  accordance  with  the  system  control 
procedure.  The  processing  system  operations  required  for  the  stabil¬ 
ization  function  are  shown  in  Figure  46  for  each  of  the  three  distributed 
processing  configurations.  The  total  number  of  instructions  executed 
and  weapon  bus  words  (data  and  interrupts)  transferred  were  derived 
and  are  shown  in  Table  16.  This  table  also  shows  the  equivalent  num¬ 
bers  for  performing  all  operations  in  a  single  processor.  For  the  cen¬ 
tral  processor  case,  the  processor  is  located  at  the  position  the  FCP 
takes  in  Figure  44.  BC  is  the  configuration  derived  from  configuration 
B  by  placing  the  single  processor  with  the  actuators.  CC  is  the  config¬ 
uration  derived  from  configuration  C  by  deleting  either  one  of  the  two 
processors  shown  and  including  all  functions  in  the  remaining  processor. 

The  total  time  allowed  to  perform  the  stabilization  function  (from 
sampling  to  delivery  of  output  data  to  the  actuators)  is  600  micro¬ 
seconds.  Sixty  microseconds  are  required  for  sampling  and  analog-to- 
digital  conversion  (20  microseconds  per  word).  Another  15  microseconds 
are  required  for  digital-to-analog  conversion  at  the  actuators.  This 
leaves  525  microseconds  for  the  required  weapon  bus  transfers  and  the 
processor  tasks.  The  processor  throughput  capability  is  a  function  of 
thn  bum  t raca m Es*ion  ram:  the  slower  the  bus  transmission  is.  the 


TABLE  15.  INSTRUCTIONS  EXECUTED/ITERATION 


FUNCTION 

SHORT 

LONG 

interrupt  service 

25 

TASK  SUPERVISOR 

75 

^  (INTERRUPT  OUTPUT  FROM  CPI 

3 

DATA  TRANSFER 

30 

stabilization  computations 

350 

20 

TABLE  16.  SYSTEM  OPERATIONS  REQUIRED  FOR  EACH  STABILIZATION 

COMPUTATION 


INSTRUCTIONS 

CONFIGURATION 

SHORT 

LONG 

WEAPON  BUS 

WORDS 

A 

350 

20 

0 

B 

683 

20 

7 

BC 

580 

20 

6 

C 

816 

20 

13 

CC 

610 

20 

9 

Semite 


Figure  46.  Stabilization  Function  Operations 
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faster  the  processor  must  operate.  For  each  configuration,  the  proccs 
sors  must  perform  the  instructions  shown  in  Table  lb.  In  the  distrib¬ 
uted  processor  case,  the  h’CP  performs  350  short  instructions  and 
20  long  instructions  for  the  stabilization  function.  The  other  instruc¬ 
tions  are  communication  control  or  interrupt  responses  and  are  shared 
by  the  two  processors.  It  must  be  remembered  that  the  two  processors 
operate  in  series.  Note  that  there  are  different  numbers  of  words  to  be 
transferred  on  the  bus  for  the  different  configurations. 

The  tradeoff  of  bus  rate  versus  required  processor  throughput 
capability  is  shown  in  Figure  47.  For  this  tradeoff  it  was  assumed  that 
long  instructions  were  performed  at  the  same  rate  as  short  instructions 
It  is  noted  that  for  the  distributed  processor  cases,  each  processor 
must  have  the  throughput  capability  shown. 

Configuration  A  has  the  lowest  throughput  requirement  per 
processor.  In  this  configuration  no  bus  transmissions  are  required. 

It  is  equivalent  to  the  GBU-15  situation.  This  configuration,  of  course, 
does  not  fit  in  with  the  modularity  concept  described  in  SectionVI  and  so 
is  not  an  allowed  configu-ration.  If  it  were  allowed,  however,  the  CP 
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.should  also  be  placed  in  the  same  spot  as  the  FCP  and  the  functions 
should  be  combined  in  a  sins>le  processor,  (The  results  of  the  cost 
analysis  reported  in  Section  LK  supports  this  arrangement.  ) 

Of  the  remaining  configurations.  C  has  by  far  the  highest  through¬ 
put  requirements  and  is  clearly  not  a  good  choice.  The  three  remaining 
configurations  have  about  the  same  throughput  requirements  per  proces¬ 
sor.  However,  B  requires  two  processors  while  CC  and  BC  require 
only  one.  There  would  seem  to  be  no  advantage  to  configuration  B. 

Configuration  CC  best  meets  the  modularity  requirements.  (It  does 
not  require  any  special  positioning  relative  to  subsystems.  )  It  is  the 
recomme nded  configu rat i on. 

The  above  results  are  consequent  to  the  necessity  to  transmit  data 
over  a  multiplexed  bus.  It  is  possible  that  other  bus  control  procedures 
would  modify  the  above  results  (alternate  procedures  were  not  investi¬ 
gated  in  this  context).  However,  no  matter  what  the  procedure  used,  the 
throughput  requirements  for  the  processors  will  always  be  higher  when 
the  bus  must  be  used  (configurations  B.  BC,  C  and  CC)  than  when  it  is 
not  used  (configuration  A). 

It  is  possible  that  some  control  procedures  will  reduce  the  peak 
processor  requirements  described  above  for  the  distributed  case.  What 
is  needed  is  a  procedure  that  treats  the  FCP  as  a  special  case,  so  that 
the  operations  of  the  CP  are  not  in  series  with  the  operations  of  the 
FCP.  This  requires  that  the  CP  dedicate  some  of  its  time  in  a  wait 
mode  (and  also  reserve  the  bus)  so  that  it  can  overlap  at  least  some  of 
Hie  system  control  process  with  the  stabilization  computations.  Such  a 
procedure  will  lower  the  peak  throughput  requirements  on  each  proces- 
,  but  not  by  as  much  as  a  factor  of  t\^'o.  Fven  if  the  requirements 
were  lowered  by  a  factor  of  two,  there  is  no  cost  advantage.  In  fact, 
the  cost  study  reported  in  Section  IX  indicates  that  the  cost  will  be 
greater  for  the  two  distributed  processors  as  compared  to  the  single 
processor  with  twice  the  throughput, 

A  strong  argument  against  the  use  of  such  control  procedures  is 
that  it  violates  the  modularity  concept.  If  thire  is  no  economic  benefit, 
then  it  should  be  eliminated  in  favor  ot  the  more  general  procedure 
used  in  the  above  analysis. 

One  possible  configuration  not  treated  in  the  above  analysis  is  that 
in  which  two  or  more  processors  are  collocated.  This  kind  of  arrange¬ 
ment  can  reduce  the  required  number  of  bus  transfers.  In  fact,  the 
number  of  bus  transfers  can  become  equal  to  that  required  for  the  single 
processor  case.  In  order  to  take  advantage  of  this  arrangement  there 
would  have  to  be  a  very  efficient  direct  I/O  connection  between  the 
processors,  such  as  a  shared  memory.  Furthermore,  the  tasks  would 
have  to  be  divided  up  differently  than  in  the  cases  analyzed  above.  In 
particular,  the  flight  control  function  could  be  divided  up.  If  one 
processor  performed  the  system  management  and  the  roll  channel  and 
the  other  processor  the  lateral  channels,  there  would  be  a  slight  reduc¬ 
tion  in  the  requirements  for  each  processor.  But  two  processors  are 


u»«d  in  this  configuration.  The  reBulle  of  the  CoEt  analyeis  iSecliun  IM) 
apply  here.  The  results  of  that  study  indicate  that  dividing  a  processing 
load  between  two  separate  processors  in  general  leads  to  increased 
costs  relative  to  a  single  processor,  unless  the  single  processor  imple¬ 
mentation  pushes  the  state  of  the  art.  The  exception  is  found  when  the 
two  prckfeBii ore  shar*;  a  large  amoutir  -f  LuX.  chared 

memory,  shared  I/O).  This  latter  case  is  the  multiprocessor  and  is 
not  really  a  distributed  configuration.  It  is  just  another  way  to  configure 
the  single  processor. 

In  summary,  separating  the  system  management  function  and  the 
flight  control  function  and  performing  them  in  different  processors  leads 
to  an  increase  in  system  cost  for  the  modular  weapon.  Each  processor 
must  have  the  same  (or  very  close  to  the  same)  throughput  capability  as 
a  single  one  would  have.  This  result  is  a  result  of  the  propagation  delay 
requirement  for  the  autopilot  and  the  fact  that  data  is  transmitted  on  a 
time  multiplexed  bus  rather  than  a  dedicated  harness.  The  propagation 
delay  requirement  for  the  autopilot  places  a  peak  throughput  requirement 
-jH  the  piocesslng  system.  As  will  be  seen  later,  this  is  tbe  require¬ 
ment  which  really  sizes  the  processor. 


The  analysis  of  the  separation  of  tiie  fligiic  control  function  from  the 
control  processor  concerned  itself  primarily  with  the  requirement  on 
peak  processor  throughput  to  accommodate  the  stabilization  function. 
There  is  no  comparable  concern  in  the  case  of  the  strapdown  inertial 
reference  function.  Therefore,  before  investigating  the  separation  of 
that  function  from  the  CP,  it  is  helpful  to  review  the  total  processing 
requirements  for  the  CORE  functions  to  give  a  basis  for  analysis. 

The  processing  requirements  are  given  in  Table  17.  The  system 
management  function  includes  a  communication  control  based  on  the  bus 
philosophy  described  in  subsection  7.  1.  This  is  the  same  control  process 
as  used  in  the  above  analysis.  All  external  subsystems  data  sources 
and  sinks  are  assumed  to  use  the  weapon  bus  for  communication  with 
the  processor. 

The  requirements  for  system  management  also  involve  the  assess¬ 
ment  of  subsystem  status  data  to  accomplish  real  time  control  of  the 
weapon  subsystems,  including  the  digital  processor  and  weapon  bus. 

The  throughput  requirement  is  based  on  the  requirements  for  the  weapon 
control  unit  (under  development  for  the  GBU-15  weapon  system)  to  per¬ 
form  the  equivalent  function.  (This  is  the  logic  function  of  the  WCU.  ) 
Provisions  have  been  made  for  the  inte rsubsystem  communications 
required  for  status  word  inputs  and  outputs.  The  system  management 
function  energizes  self-test  in  the  other  w’eapon  subsystems  and  in  the 
applicable  digital  processor  software  functions  in  response  to  status 
inputs  from  the  AGE.  The  memory  requirements  for  the  executive 
ftC'ftware  apo  Indu-dcd  in  the  s/sttm  iiianagen'ienl  Soflwcut,. 


TABLE  17.  CORE  FUNCTION  PROCESSING  REQUIREMENTS 


AVERAGE  THROUGHPUT 
KOPS 

BUS  RATE 
(words/ sec) 

FUNCTION 

PROGRAM 

SI2F 

OPERAND 

MEMORY 

TOTAL 

SHORT 

LONG 

DATA 

INTERRUPT 

FLIGHT  CONTROL 

600* 

240* 

172 

162 

10 

3600 

900 

STRAPDOWN  INERTIAL 
REFERENCE 

1700* 

540* 

103  2 

91 

12  2 

840 

225 

SYSTEM  MANAGEMENT 

700* 

500* 

407 

407 

0 

2400 

«  « 

TOTAL 

3000’ 

1280* 

682.2 

660 

22  2 

6840 

1125 

‘memory  REOUIREMENTS  GIVEN  FOR  A  SINGLE  CONFIGURATION  ONLY. 

“included  in  above  entries 

The  throughput  requirements  shown  are  average.  It  should  be  noted 
that  the  average  requirements  are  considerably  less  than  the  peak 
throughput  requirements  indicated  in  Figure  47.  In  that  figure,  a 
throughput  of  the  order  of  1.  5  million  operations  per  second  is  indicated, 
and  this  is  with  the  assumption  that  long  instructions  are  executed  at 
the  same  rate  that  short  instructions  are. 


Also  to  be  noted  is  the  fact  that  the  memory  requirements  shown 
in  the  table  are  sufficient  for  only  one  configuration.  The  complete 
modular  weapon,  with  several  configurations,  will  require  more  memory. 


7.  2.  3  Strapdown  Inertial  Reference  in  Separate  Processor 


As  shown  in  Table  17,  the  strapdown  calculations,  in  the  average 
sense,  fit  easily  into  the  peak  throughput  requirement  established  by 
the  flight  control  stabilization  function.  The  strapdown  calculations  do 
have  a  time  requirement  on  them.  The  processing  functions  associated 
with  the  strapdown  inertial  reference  itself  must  only  be  completed 
within  the  iteration  period  of  each  function.  However,  the  alignment/ 
correction  filter  computations  irust  be  completed  in  less  than  100  milli¬ 
seconds.  This  propagation  delay  effect  requires  a  throughput  capa¬ 
bility  of  about  200  KOPS.  Since  it  can  be  interrupted  by  the  flight  con¬ 
trol  computation,  it  does  not  add  to  the  peak  throughput  requirement. 
Thus,  the  strapdown  processing  can  be  included  in  the  CORE  function 
processor  without  adding  to  the  throughput  requirements. 


The  strapdown  inertial  reference  computations  could  be  performed 
in  a  distributed  processing  element  with  relatively  low  capability 
(-250  KOPS  throughput).  However,  the  required  capability  of  the  con¬ 
trol  processor  would  not  change,  and  system  cost  would  increase  due 
to  the  added  processor.  Since  there  is  no  system  advantage  to  putting 
this  function  in  a  separate  processor,  and  there  is  a  cost  penalty,  it  is 
not  a  recommended  approach. 
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In  the  context  of  the  modular  weapon,  with  a  time  multiplexed  weapon 
bus,  there  is  no  system  advantage  in  separating  either  the  flight  control 
function  or  the  strapdown  inertial  reference  function  and  performing 
these  functions  in  separate  processors.  There  is  a  cost  penalty  if  one 
does  separate  them. 

7.  3  SOFTWARE  DESIGN 

The  digital  processor  software  is  an  integral  part  of  the  modular 
weapon  system  and  must  support  the  modularity  of  the  system.  This 
software  plays  a  key  role  in  the  functional  integration  of  the  weapon 
subsystems  as  well  as  performing  many  of  the  computational  and 
decision  operations  for  individual  weapon  subsystems. 

The  digital  processor  functions  can  be  conveniently  divided  into  two 
categories.  One  is  a  group  of  functions  that  are  common  to  all  config¬ 
urations  and  are  called  the  CORE  functions.  These  functions  will  be 
performed  in  ail  weapon  configurations  regardless  of  what  subsystems 
are  included  in  the  weapon,  but  there  will  be  variations  within  these 
functions  corresponding  to  differences  between  weapon  configurations. 

The  second  category  is  called  configuration  dependent  functions.  These 
are  functions  that  are  performed  only  when  a  particular  subsystem  is 
installed  in  the  weapon,  and  only  if  the  processing  function  is  appropriate 
for  performing  in  the  digital  processor. 

The  CORE  functions  are  flight  control,  strapdown  inertial  navigation, 
and  system  management  which  includes  configuration  identification,  com¬ 
munication  control.  Sequencing,  initialization,  and  self  test.  The  CORE 
functions,  although  they  will  be  present  in  every  configuration,  will  have 
to  be  able  to  adapt  to  the  differences  among  various  configurations.  The 
flight  control  function,  for  example,  will  have  to  be  able  to  adapt  to  the 
different  aerodynamics  and  terminal  trajectories  of  the  various  config¬ 
urations.  The  system  management  function  in  particular  will  have  to  be 
able  to  identify  the  present  configuration  and  alter  the  sequencing  and 
communication  control  sub  functions  to  fit  the  hardware  modules  that 
are  actually  installed  in  the  weapon.  It  will  also  have  to  vary  the  self 
test  procedure  to  test  only  the  functions  and  systems  used  in  the 
configuration. 

The  configuration  dependent  functions  are  associated  with  specific 
midcourse  and  terminal  guidance  subsystems  which  may  be  installed  in 
the  weapon.  Examples  of  subsystem  signal  and  data  processing  func¬ 
tions  were  defined  in  the  point  designs  of  Section  V.  Although  no  speci¬ 
fic  recommendation  has  been  made  concerning  configuration  dependent 
signal  and  data  processing  functions  to  be  performed  by  the  digital 
processor,  the  factors  in  the  decision  process  are  discussed  in  sub¬ 
section  7.  6.  The  software  structure  must  be  capable  of  supporting  both 
the  CORE  functions  and  desired  functions  of  this  type.  Many  of  these 
functions  may  be  designed  into  the  software,  but  in  any  given  configura¬ 
tion  only  a  few,  if  any,  of  these  functions  will  be  performed.  It  is  the 


responsibility  of  one  of  the  CORE  functions,  system  management,  to 
determine  what  subsystems  are  installed  and  which  configuration- 
dependent  functions  are  to  be  performed,  if  any,  and  to  provide  sequenc¬ 
ing  and  communication  control  as  appropriate. 

Many  of  these  functions  include  operations  which  must  he  peiformed 
within  a  limited  amount  of  time  after  the  occurrence  of  some  event  exter¬ 
nal  to  the  digital  processor  or  some  time  event  from  the  system  clock. 
This  means  that  the  execution  of  many  of  the  processor  functions  must 
be  initiated  by  interrupts  received  by  the  processor.  Furthermore,  the 
particular  function  performed  when  an  interrupt  is  received  can  vary 
with  the  subsystems  installed  and  wdth  the  phase  of  flight.  Therefore, 
the  software  must  include  a  flexible  interrupt  structure  which  can  be 
ii'oJified  Ly  tht  feymt«a.  managen'^tR  In  aiMltlc-n,  the  sioflwBre 

must  be  able  to  grow  in  the  future  by  adding  new  software  modules  with¬ 
out  altering  the  basic  structure  of  the  software  and  without  altering 
many  existing  software  modules. 

One  program  structure  (shown  in  Figure  48)  that  has  been  used 
successful'y  in  many  small  programs  directly  interfaces  each  software 
function  with  every  other  software  function  w'ith  which  it  must  commun¬ 
icate  and  with  any  external  subsystems.  This  structure  is  adequate  for 
small  programs  and  can  be  quite  efficient  because  there  is  little  over¬ 
head  required.  How’ever,  it  suffers  from  a  large  number  of  interfaces 
which  can  grow  as  the  square  of  the  number  of  functions  making  expan¬ 
sion  of  the  system  difficult.  The  large  number  of  interfaces  also  makes 
modifications  of  any  of  the  functions  difficult  because  the  modifications 
tend  to  across  tive  iiitor facts  into  other  functions.  In  the  past 

this  type  of  structure  has  contributed  to  the  high  cost  of  softw’are  develop¬ 
ment  and  maintenance. 

A  n.orc  suitable  structure  for  the  Dl^  is  one  that  utilizes  an  execu¬ 
tive,  An  executive  is  a  collection  of  supervisory  functions  that  manage 
the  resources  of  the  processor.  All  interfaces  between  software  func- 
lijn*  of  Suftware  funclione  and  external  BuLsysteiiiE  afo  ihre-ugh 

the  executive.  With  this  structure  (shown  in  Figure  49)  the  number  of 
interfaces  only  goes  up  linearly  with  the  number  of  functions.  Changes 
in  one  software  function  do  not  propagate  into  other  software  functions 
very  often  because  of  the  isolation  provided  by  the  executive.  Also,  it 
is  a  relatively  simple  matter  to  add  more  functions  to  the  system.  The 
processor  functions  are  partitioned  into  software  modules  that  are 
largely  independent  of  each  other  except  for  the  common  data  that  they 
operate  on.  This  structure  facilitates  the  use  of  a  top-down  design 
methodology  for  developing  the  software. 

The  direct  interconnection  method  is  somewhat  faster  when  a  small 
number  of  programs  must  be  controlled,  however,  when  more  programs 
are  to  be  controlled,  it  requires  either  a  large  number  of  priority  levels 
or  some  software  routine  to  sort  out  the  priority  levels.  It  also  results 
in  a  IfcSo  generai  slructuie  which  is  liaxdei  to  modify  or  add  to.  because 
of  the  desire  for  modularity  and  the  number  of  programs,  the  use  of  a 
simple  real  time  executive  is  chosen  for  this  system. 
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DIRECT  INTERCONNECTION  OF  PROGRAM  MODULES 
RESULTS  IN  A  LARGE  NUMBER  OF  INTERFACES  AND 
EXCESSIVE  INTERDEPENDENCE  AMONG  MODULES 


Figure  48,  Direct  Interconnection  of  Program  Modules 


FLIGHT 

CONTROL 


NAVIGATION 


OTHER 


Figure  49.  Program  Structure  Using  an  Executive 
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The  executive  is  an  organized  collection  of  software  routines  (shown 
in  Figure  50)  designed  to  manage  the  processor  resources.  It  is 
I'eSpuiisible  for  inleifadiig  with  all  inleriupt  hardware  and  input/output 
equipment  and  for  supervising  the  execution  of  all  software  modules. 

The  executive  acts  as  a  buffer  between  software  modules  and  the  hard¬ 
ware  by  performing  all  input/output  operations  thereby  making  software 
modules  independent  of  the  mechanization  of  input/output  hardware.  It 
also  acts  as  a  buffer  between  software  modules,  providing  a  common 
way  uf  in,,erfacing  one  module  to  another.  Ihe  executive  is  a  permanent 
part  of  the  system  that  is  common  to  ail  configurations. 

The  processor  functions  are  partitioned  into  units  called  tasks. 

Each  task  is  a  unit  of  work  that  is  to  be  performed  as  a  result  of  some 
external  event  or  time  event  or  command  from  another  task.  Tasks 
can  range  in  size  from  a  few  instructions  to  a  few  hundred  instructions, 
and  in  execution  time  from  microseconds  to  seconds.  Some  tasks  may 
only  be  executed  once  while  others  may  be  executed  from  100  to  400  times 
per  second.  Tasks  are  characterized  by  a  unique  identification  number, 
a  starting  address,  and  a  priority.  Tasks  are  called  by  each  other  or 
associated  with  external  events  only  by  their  ID  number.  Only  the  execu¬ 
tive  needs  to  know  the  location  and  priority  of  a  task  and  since  this  infor¬ 
mation  is  contained  in  a  table,  it  can  vary  from  one  configuration  to 
another  without  the  tasks  having  to  be  changed. 
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Figure  50,  Executive  Routines 
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In  determining  how  to  partition  a  processor  function  into  tasks  some 
general  rules  should  be  followed. 

1.  Each  task  should  consist  of  a  single  operation  at  some  level 
of  abstraction  in  the  description  of  the  function.  At  a  lower  level  of 
abstraction  the  task  might  include  many  operrtions  but  there  should  be 
some  level  at  which  the  programmer  can  consider  the  task  as  a  single 
operation.  Otherwise  it  should  be  broken  down  into  smaller  tasks. 

2.  A  task  should  not  have  delay  loops  longer  than  30  p  seconds  in 
it  that  \^ait  for  sonic  cxlcriial  cvciit  lo  be  cuiliplclcd.  If  a  task  iiiust 
initiate  an  external  event,  such  as  the  transmission  of  a  block  of  data 
from  a  weapon  subsystem  to  the  DP,  and  has  no  other  operations  to 
perform  until  the  data  block  has  been  received  by  the  DP,  then  it  should 
be  broken  into  two  tasks.  The  first  task  would  initiate  the  external 
event  and  then  end  by  returning  to  the  executive.  The  second  task  would 
uMOCtiLe  vihm  thi.  data  franafer  la  complrti Du  ring  tbf^  timfi  in  betw*  f,n 
the  executive  can  start  executing  some  other  task  so  the  time  is  not 
wasted. 

3.  A  task  should  not  have  a  small  subset  of  operations  that  have 
a  niuch  higher  priority  than  the  bulk  of  the  task.  Instead  it  should  be 
partitioned  into  two  tasks  which  have  different  priority  levels.  One 
task  containing  the  bulk  of  the  operations  would  run  at  a  low  priority, 
afid  the  rciiiairiing  few  o^eralxOim  \.uuld  be  peifoiined  ixi  a  sepaiate 
task  at  a  higher  priority. 

Whenever  two  or  more  tasks  operate  on  tht  same  data,  whether 
two  tasks  are  operating  on  common  deta  from  an  external  source  or  a 
task  is  operating  on  data  produced  by  another  task,  the  common  data 
will  be  Converted  t  j  a  fuimat  and  scale  factor  and  stored  in  locations 
decided  upon  at  the  system  level.  This  will  prevent  incompatibilities 
in  data  formats  and  scaling  that  could  otherwise  occur. 

All  these  tasks  must  be  tied  together  and  executed  in  a  sequence 
appropriate  to  the  weapon  configuration.  This  will  be  accomplished 
by  two  levels  of  software.  One  of  these  levels  is  the  executive  which 
causes  software  modules  to  be  executed  in  response  to  signals  from 
external  devices  or  in  response  to  commands  from  other  software 
modules.  The  executive  does  this  without  any  knowledge  of  the  weapon 
configuration  or  what  each  module  is  supposed  to  do.  This  knowledge 
is  contained  in  the  system  management  module  which  is  the  second 
level  of  software  that  controls  the  sequence  of  execution  of  all  tasks. 

The  system  management  module  is  the  glue  that  holds  all  the  other 
tasks  together  to  form  a  working  system.  This  module  miust  interrogate 
all  the  external  devices  that  may  be  connected  to  the  processor  to  deter¬ 
mine  what  configuration  weapon  it  is  in.  After  determining  the  weapon 
configuration  it  must  set  up  linkages  that  will  cause  the  proper  tasks 
to  be  executed  to  process  the  data  available  from  the  installed  hardware 
modules  and  to  provide  the  proper  outputs  to  control  the  weapon.  This 
is  aecctnpiishtd  by  s-:ttiiig  up  tables  that  link  the  occvirt  ence  of  an 
event  to  the  execution  of  a  task.  These  tables  (shown  in  Figure  51) 
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Figure  51,  Executive  Routines  and  Tables 

define  what  task  is  to  be  executed  for  each  interrupt  received  from  an 
external  device,  for  each  block  of  data  transmitted  from  an  I/O  device, 
and  for  each  time  strobe  received  from  the  system  clock. 

To  illustrate  the  use  of  tasks  and  the  executive,  consider  the 
following  hypothetical  situation.  Some  input  device  provides  data  that 
must  be  used  in  two  different  operations  that  are  not  related  to  each 
other  except  that  they  operate  on  the  same  data.  The  software  would 
be  partitioned  into  three  tasks.  One  task,  which  will  be  called  task  A, 
would  be  responsible  for  getting  the  data  from  the  input  device,  refor¬ 
matting  the  data  to  a  common  form,  and  storing  the  data  where  it  could 
be  accessed  by  the  other  tasks.  The  other  two  tasks,  which  will  be 
called  B  and  C,  would  perform  the  required  operations  on  the  data. 

The  sequence  of  events  would  be:  The  DP  receives  an  interrupt  from 
the  input  device  indicating  that  data  is  ready.  The  interrupt  routine 
in  the  executive  would  service  the  interrupt  and  discover  that  task  A 


was  to  be  executed.  The  interrupt  routine  would  tell  the  task  supervisor 
part  of  the  executive  to  execute  task  A.  The  task  supervisor  v«  ould 
look  up  task  A  in  the  task  ID  table  to  discover  its  location  and  priority. 

The  priority  determines  which  task  will  be  executed  first  when  several 
are  waiting  to  be  executed  at  the  same  time.  When  task  A  is  the  highest 
priority  task  waiting,  the  task  supervisor  will  start  it  executing.  Task 
A  reformats  the  data  from  the  input  device  and  stores  it,  and  then  it 
tells  the  task  sape-r visor  to  execute  task  B  aiio^  t’.  Tast*  \  i» 
finished.  The  task  supervisor  will  execute  tasks  B  and  C  when  they 
are  the  highest  priority  tasks  waiting. 

With  this  arrangement  either  task  b  or  C  could  be  modified  or 
eliminated  without  affecting  the  other.  And  task  A  does  not  know  where 
B  and  C  are  located,  therefore,  they  can  be  moved  about  without  chang¬ 
ing  A.  If  the  input  device  is  replaced  by  another  device  which  formartled 
the  data  differently  only  task  A  would  have  to  be  changed  to  reformat 
the  data. 

When  the  tasks  are  placed  in  physical  rntroovy  mndulps  each  module 
has  an  initialization  section  which  begins  at  the  first  location  in  the 
memory  module.  This  initialization  section  tells  the  executive  what 
tasks  are  in  this  module,  and  what  their  starting  locations  and  priorities 
are.  During  DP  initialization  the  initialization  section  of  each  hardware 
memory  module  is  executed.  This  lets  the  executive  know  where  all 
tasks  are  located  so  that  these  lucatlulis  do  hOt  have  to  be  fiA.cd  for  all 
configurations. 

7.4  DIGITAL  PROCESSOR  ARCHITECTURE 

The  architecture  of  the  digital  processor  is  concerned  with  the 
instruction  set  to  be  executed  and  the  facilities  required  to  support  the 
instruction  set.  As  discussed  previously,  these  architectural  consid¬ 
erations  are  strongly  dependent  on  the  functions  to  be  performed,  the 
processes  involved  in  these  functions,  and  the  total  weapon  system 
characteristics.  The  specification  of  the  processor  instruction  set  and 
support  facilities  is  required  to  determine  the  requirements  placed  on 
the  hardware  implementation  of  the  processor  by  the  system  functions. 
The  interaction  of  implementation  cost  with  processor  architecture  was 
considered  in  the  derivation  of  the  instruction  set  and  processor  facilities 
presented  in  this  section.  These  architectural  parameters  were  used 
to  derive  the  memory  and  throughput  data  presented  in  the  previous 
sections  of  this  report. 

The  processing  requirements  derived  in  this  study  are  based  on  a 
general  purpose  instruction  set.  The  diversity  of  processing  functions 
and  types  of  operations  involved  in  these  functions  does  not  allow  the 
development  of  a  special  purpose  instruction  set.  The  instruction  set 
has  been  organized  in  five  major  categories  as  shown  in  Table  18. 

catvgcrit  a  At*  geiru  ric  to  all  digital  procv  sacra  but  tlK'  ituppuri 
facilities  for  each  instruction  type  in  these  categories  have  been  defined 
in  accordance  with  the  system  characteristics.  The  dynamic  instruction 
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TABLE  18.  INSTRUCTION  CATEGORIES 


CATEGORY 

DYNAMIC  EXECUTION,  percent 

DATA  TRANSFER 

37 

INDEX  REGISTER  MANIPULATION 

S 

ARITHMETIC  AND  LOGICAL 

20 

TRANSFER  OF  CONTROL 

37 

SYSTEM  CONTROL 

1 

execution  mix  in  this  system  is  similar  to  the  mix  encountered  in  other 
digital  processors  used  for  real-time  process  control.  The  mix  shown 
in  Table  18  was  derived  by  analysis  of  the  software  pertinent  to  the 
CORE  functions. 

The  data  transfer  instructions  provide  for  all  transfers  of  data 
among  the  arithmetic  unit  registers,  index  registers,  and  operand 
memory.  Operands  may  also  be  furnished  to  the  arithmetic  or  index 
registers  by  the  program  memory.  All  data  storage  elements  required 
for  interfacing  the  digital  processor  with  the  other  weapon  subsystems 
including  the  weapon  bus  are  considered  part  of  operand  memory.  Both 
direct  and  indexed  addressing  modes  are  required  for  all  data  transfer 
instructions  involving  operand  memory,  and  all  operand  memory  loca¬ 
tions  must  be  addressable  in  both  modes.  Sixteen  index  registers  are 
required  by  the  functions  to  be  performed  in  the  digital  processor. 

Index  registers  are  dedicated  to  the  executive  software  functions  to 
improve  the  efficiency  of  the  executive  software  which  is  in  series  with 
all  digital  processor  operations.  A  very  large  number  of  index  registers 
would  be  required  if  registers  were  dedicated  to  the  applications  pro¬ 
grams.  The  remaining  index  registers  are  shared  by  the  applications 
programs,  and  require  that  their  contents  be  saved  and  restored  if  one 
program  is  interrupted  by  a  higher  priority  application  program.  To 
perform  the  save  and  restore  function,  data  transfers  between  operand 
memory  and  the  index  registers  are  required.  The  data  transfer 
instructions  provide  transfers  of  data  between  any  two  registers  or 
between  any  register  and  any  operand  memory  location. 

The  index  register  manipulation  instructions  involve  the  modification 
of  the  contents  of  the  index  registers.  The  primary  uses  of  the  index 
registers  are  address  control  for  processing  array  data,  control  of 
iterative  operations  (loops),  and  argument  transfer  (indexed  addressing) 
for  subroutines.  Approximately  70  percent  of  all  arithmetic  and  data 
transfer  instructions  use  the  indexed  addressing  modes.  Variable 
increment  and  decrement  instructions  are  required  for  array  data 
addressing.  Occasionally,  more  complex  index  register  data  modifi¬ 
cation  is  required.  Data  transfers  between  the  arithmetic  registers 
and  the  index  registers  allow  the  full  arithmetic  instruction  capability 
to  be  used  for  index  register  data  modification.  A  decrement  and 
branch  on  zero  instruction  is  required  for  iterative  operations. 
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A  complete  set  of  arithmetic  and  logical  instructions  is  required 
for  single  precision  operands.  A  single  precision  word  length  of  16  bits 
is  adequate  for  the  majority  of  the  computations  required  by  the  DP 
processing  functions.  The  higher  precision  computations  are  performed 
by  double  precision  software  routines,  and  require  that  computation 
aids  be  provided  in  the  implementation  and  instructions  using  these  aids 
be  provided.  Instructions  which  allow  software  floating  point  routines 
to  be  written  are  required  to  support  the  few  computations  with  large 
dynamic  range.  Arithmetic  instructions  involving  both  arithmetic 
registers  and  operand  memory  are  required.  At  least  two  general 
purpose  arithmetic  registers  are  required.  Both  indexed  and  direct 
addressing  modes  are  required  for  instructions  using  operand  memory. 
The  multiply  and  divide  instructions  account  for  3  percent  of  all  instruc¬ 
tions  executed.  This  relatively  low  percentage  is  not  an  indication  of 
the  computational  complexity  of  the  functions  performed,  but  rather  due 
to  the  emphasis  on  weapon  control  by  the  processor. 

The  high  percentage  of  transfer  of  control  instructions  in  the  dynamic 
instruction  mix  is  a  result  of  both  the  modular  software  structure  and 
the  decision  processes  involved  in  the  real  time  control  of  the  weapon 
subsystems.  Many  of  the  softw'are  modules  are  general  purpose  sub¬ 
routines  requiring  subroutine  call  and  return  instructions.  Both  inomedi- 
ate  and  indirect  subroutine  address  specifications  are  available.  Indirect 
addressing  allows  many  alternative  subroutines  to  be  called  from  a  single 
program  statement  by  setting  up  the  branch  address  as  a  function  of  sys¬ 
tem  state.  An  indirect  branch  capability  is  also  allowed.  A  subroutine 
return  stack  with  at  least  32  levels  is  required  to  support  software  modu¬ 
larity  and  allow  interrupt  capability.  Conditional  branching  instructions 
which  test  arithmetic  computational  status,  stored  function  status,  and 
the  status  of  the  other  w'eapon  subsystems  are  required  for  control  of 
the  weapon  functions.  The  logic  instructions  in  conjunction  with  condi¬ 
tional  branching  on  arithmetic  unit  status  provide  system  status  assess¬ 
ment.  The  status  of  external  subsystems  is  contained  in  operands 
either  received  via  the  weapon  data  bus  or  set  as  a  result  of  weapon 
bus  interrupts.  However,  status  storage  must  be  provided  both  to  store 
coiiiptitaliuii  funcHun  stalv  ff  pfcvicAia  U-^rati-jns  of  tltt  funetiotj 
for  subsystems  which  directly  interface  with  the  digital  processor,  e.g.  , 
the  weapon  bus  controller. 

A  vectored  priority  interrupt  capability  must  be  provided  to  syn¬ 
chronize  the  operations  of  the  DP  with  the  operation  of  the  other  weapon 
subsystems.  Eight  levels  of  interrupt  are  adequate  not  only  for  executive 
software,  but  also  to  provide  for  simple  synchronization  of  operations 
concerned  with  other  subsystems  which  may  directly  interface  with  the 
processor.  The  system  control  instruction  category  is  concerned  with 
software  control  of  these  interrupts  and  with  the  setting  of  the  processor 
status  storage  states. 

This  instruction  set  defines  the  functional  data  and  control  transfer 
paths  which  must  be  present  in  the  processor.  However,  the  instruction 
set  requirements  must  be  considered  in  the  context  of  the  throughput 
requirements  in  the  hardware  implementation  of  the  processor.  The 
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dynamic  instruction  execution  mix  is  useful  in  the  optimum  allocation 
of  processor  hardware  resources  to  functional  elements  implied  by  the 

instruction  set. 

Many  hardware  structures  may  be  considered  for 
implemeLation  of  the  processor,  the  optimum  structure  is  highly  depen- 
dJV  on  rh--  available  technology.  The  two  breadboard  processors  con¬ 
structed  on  this  program  are  implementation  examples  of  the  digital 
processor  architecture  discussed  in  this  section.  These  breadboard 
processors  do  not  implement  the  complete  instruction  set  specified  for 
She  digital  processor,  but  the  differences  are  minor  and  are  the  result 
of  evaluating  the  breadboard  processor  performance  o  ' 

tem  functions  to  determine  the  required  instruction  set.  The  through- 
put  capability  of  the  two  breadboard  processors  for  the  specified  instruc- 
tTon  mix  is:  1.  85  MIPS  (DP  1).  2.  3  MIPS  (DP  2).  The  throughput 
capability  was  derived  by  assuming  equal  frequency  of  ^ 

each  instruction  in  a  category  to  determine  the  average 
category,  and  then  weighting  these  average  speeds  accordinj  to  the 
sfec!ned  instruction  mix.  The  primary  factor  causing  the  dHterence 
in  throughput  capability  is  processor  clock  rate,  but  there  ^.re  so 
iLtruction  set  differences  also.  Either  of  these  breadboard  Processo  s 
meet  the  peak  throughput  requirements  discussed  in  the  previous  sectio 

for  the  CORE  functions. 

7,5  digital  processing  SYSTEM  REQUIREMENTS_ 

In  the  preceding  subsections,  a  digital  processing  system  configu- 
ration  was  defined,  \he  functions  to  be  performed  dtgi^l  proces 

sor  were  identified,  and  digital  processor  architectural  consideratio 
wpre  oresented.  Digital  processor  design  parameters  have  been 
developed  for  a  iimited,  but  representative,  set  of  weapon  configurations. 

The  generai  purpose  instruction  set  and  support  facilities  identified 
for  tL  digUal  processor  are  capable  of  performing  all  required  coniputa- 
[ronal  and"cont?ol  operations  for  the 

throughout  requirements  have  been  developed  using  this  instruction  s 
o  perform^eTresentative  examples  of  the  digital 

The  requirements  derived  so  far  are  base  requirements  That  is  the 
throughput  requirements  were  just  that  necessary  to  perform  the  defi 
CORE  functions  and  the  memory  requirements  pertain  to  a  con¬ 

figuration.  It  is  now  necessary  to  consider  the  total  modular  weapo 
system  (including  all  configurations),  and  to  determine  an  appropriate 

factor  for  growth. 

7,5.1  Processor  Throughput  Requirements 

The  determining  factor  for  throughput  is  the  propagation  delay 
requirement  for  the  autopilot  stabilization  function  In  subsection  7  2, 
thTrequired  processor  operations  to  perform  this  function  were  given, 
using  the  d2  gl-n  there  one  can  determine  the  required  processor 


93 


throughput.  Let  tg  be  the  time  to  perform  a  short  instruction  and  t^ 
the  time  to  perform  a  long  instruction.  Then  let 

t  =  K  t  (1) 

J-i  s 

The  throughput  for  short  instructions  is  the  inverse  of  tg.  The  required 
tg  is  given  by 

525  X  10"^  -  W  T 

t - w  (2) 

s  350  +  N  +  20  K  '  ' 

where 

W  =  number  of  words  transmitted  on  the  bus  during 
the  time  interval  allotted  to  the  process 

T  =  time  required  to  transmit  one  word 
w 

N  =  number  of  instructions  required  for  system 
management  and  interrupt  responses. 

Now  define: 

T^  =  time  spent  doing  system  management  functions 

T^  =  time  spent  doing  the  stabilization  computations  ^ 

T  =  T,  +  T,  =  525  X  10"^  -  W  T 
12  w 

For  the  selected  processing  system  configuration,  N  =  260  and 
W  =  9.  In  order  to  choose  a  value  for  T-^,  examine  Figure  47.  Noting 
that  required  processor  throughput  capability  is  a  monotonically 
increasing  function  of  T.^,  it  is  desired  to  choos  e  T^  as  small  as  is 
practical.  It  has  earlier  been  noted  that  a  bus  transmission  rate  of 
100,000  words  per  second  is  a  practical  goal  for  the  modular  weapon 
(T^  =  10  microseconds).  Higher  rates  can  be  achieved,  but  the  figure 
does  not  indicate  a  substantial  decrease  in  processor  requirements  by 
doubling  the  bus  rate.  Therefore,  T^  =  IQ  microseconds  is  chosen. 

Using  the  above  relations,  the  required  throughput  foi^hort 
instructions  has  been  plotted  in  Figure  52.  This  curve  can  also  be 
interpreted  as  the  mean  throughput  the  processor  must  exhibit  during 
the  time  interval,  Tj.  § 

Another  quantity  of  interest  is  the  mean  throughput  during  the 
total  interval,  T.  This  is  also  shown  in  Figure  52.  It  may  be  noted 
that  during  this  period  the  average  instruction  mix  ratio  is  3  percent 
longs  to  97  percent  short  instructions. 

To  complete  the  picture,  the  mean  throughput  during  the  interval, 
T2,  has  b  een  calculated  and  is  also  shown  in  the  figure.  During  this 
period,  the  instruction  mix  includes  about  5  percent  longs. 
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The  expected  average  percentage  of  long  instructions  for  the  total 
CORE  functions  is  about  3  percent  as  may  be  seen  by  referring  to 
Table  17.  Thus,  the  mix  during  the  interval,  T,  is  representative  of 
the  total  CORE  functions.  Therefore,  the  1.45  x  10^  instructions  per 
second  required  on  the  total  interval,  T,  is  taken  as  the  base  require¬ 
ment  for  the  digital  processor  (with  an  instruction  mix  containing 
3  percent  long  instructions). 

There  is  always  a  bit  of  subjectivity  involved  in  choosing  a  growth 
factor.  Reference,  again,  to  Table  17  shows  a  fairly  comfortable 
growth  factor  with  respect  to  average  throughput.  However,  the  peak 
throughput  requirements  over  the  weapon  life  may  be  greater  than  the 
identified  value  for  several  reasons.  The  principal  stabilization 
tion  requirements  affecting  peak  throughput  are  propagation  delay  and 
computational  complexity.  These  parameters  are  primarily  a  function 
of  the  weapon  aerodynamic  configuration,  and  variations  could  produce 
a  significant  increase  in  peak  requirements.  In  addition,  other  weapon 
configurations  may  have  a  second  time  critical  function.  Within  t  e 
CORE  function  definition,  the  most  likely  function  of  this  type  is  a 


critical  data  transfer  which  may  be  required  during  the  stabilization 
loop  computation  period.  Tf  an  interrup*^  ifi  received  from  an  external 
subsystem  during  this  period,  the  peak  throughput  requirement  is 
increased  by  approximately  16  percent,  even  if  the  implied  task  is  not 
immediately  executed.  This  type  of  interrupt  does  not  affect  aero¬ 
dynamic  stability  if  its  frequency  of  occurrence  is  low,  but  this  cannot 
be  guaranteed  for  all  weapon  configu:^tions.  In  any  case  it  appears 
risky  to  commit  to  a  design  in  which  there  is  no  apparent  margin.  It 
is  felt  that  a  margin  of  at  least  50  percent  over  the  base  requirement 
is  a  good  practice.  (This  would  not  be  an  adequate  margin  for  a  require¬ 
ment  based  on  average  throughput,  however.  )  The  base  requirement 
is  1.45  MIPS,  Therefore,  with  a  50  percent  margin  above  the  base, 
the  recommended  requirement  is  2.2  MIPS  with  the  given  instruction 
mix  (3  percent  long  instructions). 

The  above  throughput  requirement  should  be  checked  for  compati¬ 
bility  with  average  requirements.  Table  17  gives  the  average  as  just 
under  900  KOPS.  This  is  a  15  percent  margin  above  the  base  which 
should  be  adequate.  It  should  be  noted  that  the  above  requirements  are 
contingenl  un  aehi..ving  a  Iais  tr&iisuiissiun  ral^  uf  I’Jv  Is  words 

per  second. 

7.5.2  Processor  Program  Memory  Requirements 

The  program  size  requirements  developed  previously  only  pertain 
to  a  single  representative  weapon  configuration.  A  growth  factor  must 
be  applied  to  account  for  computational  complexity  variations  over  all 
weapon  configurations.  The  adequacy  of  this  type  of  program  memory 
space  specification  depends  on  weapon  assembly  procedures,  since  it 
implies  that  only  the  software  pertinent  to  the  particular  weapon  con¬ 
figuration  is  contained  in  the  digital  processor.  The  digital  processor 
program  memory  must  be  non-volatile,  since  its  contents  must  be 
retained  from  the  time  of  software  loading  until  completion  of  the  weapon 
mission  with  no  external  power  applied  to  the  weapon.  Furthermore, 
the  memory  implementation  must  be  compatible  with  the  processor 
throughput  specification. 

The  most  obvious  program  memory  implementation  which  allows 
each  weapon  to  only  contain  the  pertinent  software  is  a  read/writt: 
memory  which  is  loaded  during  weapon  assembly.  However,  the  only 
read/write  memory  technology  of  sufficient  speed  is  volatile  and  would, 
therefore,  require  power  to  be  applied  continuously  after  weapon 
assembly.  Hierarchical  memory  systems  using  a  combination  of  slow 
and  fast  read/write  storage  elements  can  provide  a  non-volatile  program 
memory,  but  imply  high  complexity  and  cost. 

A  read-only  program  implementation  provides  the  required  speed 
and  is  non-volatile.  However,  to  achieve  minimum  program  space 
would  require  that  unique  program  memory  elements  be  available  for 
each  weapon  configuration.  The  appropriate  memory  elements  could 
either  be  inserted  in  the  processor  at  the  time  of  weapon  assembly  or 
be  perriianently  installed  Hi  a  pioctsSur  wlilcli  could  then  only  be  used 
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with  a  single  configuration.  Neither  of  these  options  are  desirable 
because  of  the  implied  proliferation  of  configuration  items  and  corres¬ 
ponding  weapon  configuration  control  problems. 

nf  the  options  Hiscufl.sc  d  atxive,  a  non-volatile  memory  loaded  at 
weapon  assembly  time  does  not  violate  the  modularity  concept  since 
it  is  assumed  that  the  w'eapon  does  undergo  a  systems  test  at  the  end 
of  weapon  assembly  anti.  tb*.  apprvjpr iati^  projtra'n  roajld  Ik  loaded  at 
that  time.  The  option  with  the  read-only  memory  modules  for  the 
appropriate  mission  loaded  at  weapon  assembly  does  violate  the  modu¬ 
larity  concept. 

Since  the  hierarchical  memory  does  have  some  system  attractive¬ 
ness,  it  is  worthwhile  examining  the  cost  question  a  little  further. 
Military,  bipolar,  random  access  memories  of  the  requisite  speed  are 
expected  to  cost  about  eight  times  read-only  memory  costs,  bit  for  bit. 
(See  Section  IX.  )  Thus,  even  neglecting  the  cost  for  the  non-'-olatile 
storage,  the  hierarchical  system  would  have  to  reduce  total  memory 
requirements  by  at  least  a  factor  of  eight  to  become  attractive  from 
an  economical  point  of  view.  This  is  not  likely. 

Since  none  of  the  above  memory  options  can  be  wholeheartedly 
recommended,  it  is  necessary  to  base  memory  address  space  require¬ 
ments  on  some  other  approach  that  is  both  practical  from  a  system 
standpoint  and  economically  attractive.  Such  an  approach  is  to  store 
the  entire  program  for  ail  configurations  ir  read-only  memory.  As 
indicated  in  Section  IX,  the  cost  trends  extrapolate  to  ai  out  uitt  Unfh 
of  a  cent  per  bit  in  the  early  1980's.  The  packaging  density  is  high  so 
that  required  board  space  will  be  small.  This  approach  does  make 
system  program  changes  somewhat  more  difficult,  however,  consider¬ 
ing  the  state  of  technology,  it  is  the  most  practical  approach.  Memory 
address  space  requirements  are  based  on  it. 

The  identified  storage  requirement  for  the  CORE  functions  is 
3000  words  (see  Table  17)  for  a  single  configuration.  Since  the  weapon 
system  is  not  well-defined  at  the  present  time,  it  is  difficult  to  make 
an  estimate  of  program  requirements  for  all  configurations.  However, 
an  estimate  can  be  made  of  the  additional  memory  required  for  adding 
a  new  configuration  to  the  existing  system.  It  was  estimated  in  Sec¬ 
tion  IV  that  adding  a  new  airframe  would  increase  the  program  require¬ 
ment  for  the  flight  control  by  less  than  300  words.  Adding  a  new  mid¬ 
course  guidance  mode  can  increase  the  strapdown  inertial  subsystem 
requirements  by  requiring  a  new  program  to  filter  the  update  data. 

The  filter  requirement  in  the  base  program  is  about  600  words.  The 
new  filter  could  require  substantially  less  if  some  of  the  routines  of 
the  first  filter  can  be  used.  It  could  require  more  if  additional  states 
were  required.  As  an  estimate,  let  us  use  600  words. 

It  is  estimated  that  adding  a  new  subsystem  will,  on  the  average, 
increase  the  system  management  program  by  30  to  40  words.  The 
ru'cariiu.ir'iidi-d  iyeTi'n  tfveign  liaw  16  t^uTniinal*  or  the  wraptin  boj.  Ty.'o 
of  these  are  dedicated  (DP  and  avionics).  Therefore,  a  configuration 
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c'^iange  could  introducv.  14  new  suHsystnn-ic?,  This  would  add  about 
600  words  to  the  system  management.  Adding  the  above  gives  a  total 
of  1500  words  additional  program  memory  for  adding  a  completely 
new  configuration.  The  precision  of  the  above  number  is  open  to 
question,  but  it  is  probably  more  precise  than  an  estimate  of  the  number 
of  configurations  that  will  be  in  the  system. 

An  alternative  way  to  estimate  prograni  size  is  by  estimating  the 
probable  number  of  additional  major  subsystems  that  w  ould  be  added  to 
the  base  configuration.  Table  19  shows  an  attempt  at  this.  The  two 
estimates  presented  above  are  not  intended  to  convey  the  impression 
that  an  accurate  aaseasinent  of  j.  iugram  memory  size  has  bv^v^n  iiiadt,. 
However,  two  conclusions  can  be  drawn: 

•  Additional  configurations  can  easily  add  4000  words  to  the 
base  requirement 

•  By  the  time  4000  words  are  added  one  has  a  very  complex 
modular  system. 

In  other  words,  a  total  of  8000  words  of  program  memory  is  enough 
for  a  rather  complex  modular  weapon  system.  Clearly,  additional 
subsystems  can  be  added  without  limit,  but  it  is  doubtful  if  operational 
considerations  can  justify  a  weapon  system  with  more  alternatives  than 
are  given  in  Table  18  or  which  has  more  than  four  completely  different 
configurations.  Applying  a  100  percent  margin  to  the  above  estimate 
to  account  for  uncertainties  and  for  growth  gives  a  minimum  of  16  K 
words  for  program  address  space.  It  is  stressed  that  this  is  a  minimum 
requirement.  While  this  amount  of  memory  would  not  be  installed  in 
initial  systems,  the  processor  must  hav(*  provision  for  adding  memory 
as  the  system  grows. 


TABLE  19.  ESTIMATED  INCREASE  IN  PROGRAM  MEMORY 

REQUIREMENTS 


GENERAL  SUBSYSTEM 

NUMBER  ADDED 

ADDITIONAL 

PROGRAM  REQUIREMENTS 
(words) 

TERMINAL  GUIDANCE 

6 

240 

MIDCDURSE  GUIDANCE 

4 

2400  1  160 

AIRFRAMES 

3 

900 

MISCELLANEDUS  ADDITIONAL 

SUBSYSTEMS 

10 

400 

TOTAL 

A.  100 

7,5.2)  Processor  Operand  Memory  Requirements 


The  operand  memory  must  include  provisions  for  all  computational 
variables  and  constants  pertinent  to  the  software  contained  in  the  proces¬ 
sor.  All  variables  are  stored  in  read/write  memory  elements,  and 
blocks  of  memory  can  be  dedicated  for  each  class  of  functions  performed 
by  the  prov.esSof.  thus  pf^viding  sufficiej-  (  capacity  fur  all  weapon  con¬ 
figurations  within  a  minimum  memory  space.  As  previously  discussed, 
read/write  memory  teclinology  with  speed  compatible  with  tlie  throughput 
requirement  is  volatile  and,  therefore,  subject  to  having  its  contents 
modified  by  power  transients.  The  majority  of  the  variables  can  be 
accidently  changed  with  minimal  effect  on  weapon  performance.  How¬ 
ever,  some  parameters  are  critical,  e.  g.  ,  target  location  for  the 
inertial  reference  navigation  function,  and  must  be  protected.  A  non¬ 
volatile  read /write  memory  of  256  words  provides  sufficient  capacity 
for  mission  critical  parameters  and  allows  system  recovery  in  the 
event  of  power  transients.  The  operand  memory  space  which  rnust  be 
provided  for  storage  of  constants  depends  on  the  method  of  loading  the 
software  in  the  processor.  However,  just  as  in  the  case  of  the  program 
memory,  read-only  memory  would  appear  to  be  the  most  practical 
approach  with  present  technology.  Memory  address  space  requirements 
are  estimated  on  this  basis.  Reference  to  Table  17  shows  that  the 
required  operand  memory,  for  a  single  configuration,  is  about  one  half 
of  the  program  memory  size.  The  largest  part  of  this  is  constant 
memory  associated  with  the  various  subsystems.  It  may  be  expected 
that  constant  storage  requirements  will  grow  at  the  same  rate  as  pro¬ 
gram  memory  as  new  subsystems  are  added.  Requirements  on  read/ 
write  memory  will  grow  at  a  slower  rate,  but  it  represents  a  smaller 
part  of  the  total  requirement  than  the  constants.  Based  on  the  above 
considerations,  the  ratio  of  required  operand  memory  to  required 
program  memory  should  decrease  somewhat.  However,  it  is  not 
expected  to  decrease  enough  to  allow  a  4  K  address  space  to  have  suf¬ 
ficient  margin.  Therefore,  an  operand  memory  address  space  of  8  K 
words,  minimum,  is  specified. 

7.5.4  Weapon  Bus  Requirements 

The  characteristics  of  the  preferred  weapon  bus  were  presented 
in  subsection  7.  1.  Here,  some  performance  related  parameters  are 
specified. 

Bus  Word  Rates 

A  weapon  bus  word  rate  of  100  K  words  per  second  is  required  to 
be  compatible  with  the  specified  processor  throughput  and  system 
communication  requirements  for  time  critical  functions.  The  data 
bus  rate  is  based  on  16  bits  data  content  for  data  words.  This  data 
content  is  compatible  with  both  the  processor  word  size  and  the  data 
word  size  of  the  Stores  Management  System  interface  with  the  avionics. 
Thus,  format  conversion  complexity  is  minimized  al  these  piinie  intei - 
face  points.  Most  other  weapon  subsystem  parameters  have  less  than 
16  bits  quantization,  allowing  all  message  words  to  have  a  common 
format.  Subsystem  data  can  either  be  transferred  in  packed  format 
or  by  transferring  an  appropriate  number  of  fill  bits  in  the  16  bit  data 


field,  depending  on  desired  subsystem  data  format.  The  word  rate 
capability  is  required  for  each  of  the  communication  paths  (data  and 
Interrupt).  The  average  word  rate  on  each  bus  for  representative 
weapon  configurations  implies  a  low  bus  occupancy  factor  and,  there¬ 
fore,  good  response  for  critical  transfers. 

Transmission  Reliability 

The  transmission  reliability  requirement  is  based  on  allowing  no  more 
than  one  word  error  per  100  missions,  on  the  average.  For  a  typical 
weapon  mission  of  1000  seconds  duration  and  an  average  bus  rate  of 
10  K  words  per  second,  it  is  required  that  the  probability  of  word  error 
be  less  than  10-9.  A  word  error  is  defined  as  accepting,  as  correct, 
a  word  with  one  or  more  erroneous  bits. 

Considering  that  the  majority  of  the  bus  transfers  are  associated 
with  data  which  is  periodically  renewed,  the  occurrence  rate  of  missile 
critical  errors  is  much  lower  than  one  per  hundred  missions. 

7.6  CONFIGURATION  DEPENDENT  PROCESSING  FUNCTIONS 

Besides  the  CORE  functions,  there  are  a  number  of  other  weapon 
functions  which  affect,  and  are  affected  by,  the  CORE  processing  sys¬ 
tem.  These  functions  differ  from  one  weapon  configuration  to  another 
and  are  called  configuration  dependent  functions. 

Some  of  these  functions  could  be  performed  in  the  digital  processor. 
However,  whether  or  not  they  are  performed  in  the  processor,  there 
are  data  transmission  requirements  associated  with  them.  While  these 
requirements  have  no  measurable  effect  on  required  processor  through¬ 
put  capability,  they  do  affect  memory  requirements.  These  functions 
are  discussed  below  in  the  context  of  the  three  weapon  configurations. 

Candidate  configuration  dependent  processing  functions  from  the 
point  designs  of  Section  V  for  the  three  weapon  configurations  are 
identified.  The  requirements  placed  on  the  digital  processor  (DP)  by 
each  function  are  shown  for  two  conditions:  performing  the  function  in 
the  DP,  and  performing  the  function  in  another  weapon  subsystem.  The 
effect  of  the  added  requirements  on  the  baseline  design  requirements 
and  the  effect  on  the  other  weapon  subsystems  are  discussed  for  each 
configuration. 

7.6.1  Weapon  Configuration  I 

In  addition  to  the  CORE  functions,  the  inertial- body  coordinate 
conversion  and  two  different  portions  of  the  correlation  function  of  the 
RAC  subsystem  were  identified  in  the  point  design.  The  DP  require¬ 
ments  associated  with  these  functions  are  shown  in  Table  20. 

The  inertial-body  coordinate  conversion  computations  can  easily 
be  performed  by  the  baseline  DP  configuration  with  no  increase  in 
requirements.  If  this  function  is  not  performed  in  the  DP,  a  general 
purpose  processor  is  required  in  the  RAC  subsystem.  Although  the 
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TABLE  20.  DP  REQUIREMENTS  FOR  RAC  SUBSYSTEM  FUNCTIONS 


INUNCTION 

I  B  COORDINATE 
CONVERSION 


CORRELATION 
INTERFACE  @ 

CORRELATION 

interface  @ 

CORRELATION 


PROGRAM  OPERAND 
LOCATION  SI2F  MEMORY 


THROUGHPUT, 

KOPS 

SHORT  LONG 


BUS  RATE 
(words/ sec) 

DATA  INTERRUPT 


35K  1090 


performance  requirements  on  that  processor  are  minimal,  RAC 
subsystem  cost  would  be  increased. 

The  correlation  function  computations  could  be  performed  by  the 
DP  for  either  interface  definition  {slight  throughput  increase  for  inter¬ 
face  ®  )  if  total  average  throughput  were  the  only  consideration, 
ever  the  iteration  rate  for  both  interface  definitions  is  commensurate 
or  higher  than  the  iteration  of  the  critical  stabilization  function.  The 
correlation  computations  for  interface  ®  would  require  additional 

operations  during  the  critical  propagation  de  ay  ‘"/^rrela- 

substantial  increase  in  DP  throughput  capability.  Selection  of  correla 
Hon  interface  ©  would  result  in  a  smaller  increase  in  DP  throughput 
capability,  but  U,  nevertheless,  undesirable.  Therefore,  it  is  recom- 
mended  that  the  entire  correlation  processing  be  performed  within 
RAC  subsystem. 

7.6.2  Weapon  Configuration  II 

The  configuration  dependent  functions  identified  in  the  point  design 
are  the  LORAN  position  processing,  the  data  link  message  eco  it^, 
and  the  line  and  field  signal  processing  for  the  EO  meeker  The 
requirements  associated  with  these  functions  are  shown  in  Table  21  . 

Both  the  LORAN  positioning  processing  and  EO  data  link  message 
decodtag  prLent  a  minimal  addition  to  the  CORE  function  requirement., 
The  position  processing  would  require  a  general  purpose  process  r 
within  the  LORAN  subsystem  which  cannot  be  justifmd.  By  performing 
the  message  decoding  function  in  the  DP,  the  data  link 
the  weapon  bus  is  greatly  simplified  and  the  difference  in  DP  require¬ 
ments  is  negligible.  The  combination  of  line  and  field  processing  for 
the  EO  seeker  cannot  be  performed  in  the  DP  without  a  large  ^^^^ease 
in  DP  throughput.  This  is  primarily  due  to  the  high 
the  line  processing.  The  field  processing  computations  can  easily 
perform^  by  the  DP  with  the  baseline  configuration  definition, 

Ler,  the  field  processing  interface  for  which  these  requirements  hav 
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TABLE  21  .  DP  REQUIREMENTS  FOR  LORAN,  DATA  LINK,  EO  SEEKER 

FUNCTIONS 


THROUGHPUT, 

KOPS 


BUS  RATE, 
(words/sec) 


FUNCTION 

LOCATION 

PROGRAM 

SIZE 

OPERAND 

MEMORY 

SHORT 

LONG 

DATA 

INTER 

POSITION 

PROCESSING 

LORAN 

10 

0* 

0  2 

0 

5 

1 

DP 

120 

50 

3  2 

0  01 

5 

30 

MESSAGE  DECODING 

DATA 

LINK 

10 

5 

8.0 

0 

270 

30 

DP 

110 

20 

25.0 

-0 

270 

30 

LINE  +  FIELD 

DP 

250 

40 

115C.0 

37.0 

83,500 

2625 

FIELD  ONLY 

DP 

215 

40 

28.0 

1.1 

1380 

60 

LINE  I  FIELD 

EO 

1 

20 

-0 

12.0 

1  0- 

240 

60 

been  derived  is  not  compatible  with  existing  EO  seeker  implementations. 
Only  the  requirements  shown  for  both  line  and  field  processing  in  the 
EO  seeker  are  germane  to  configurations  using  existing  EO  seekers. 


7.  6.  3  Weapon  Configuration  III 


The  configuration  dependent  functions  identified  in  the  point  design 
are  the  data  link  m  sage  decoding,  and  the  line  and  field  processing 
for  the  HR  seeker.  The  DP  requirements  associated  with  these  func¬ 
tions  are  shown  in  Table  22  . 


The  requirements  for  the  message  decoding  function  are  identical 
to  those  presented  for  Configuration  II.  The  average  throughput  require¬ 
ments  for  performing  both  the  line  and  field  processing  in  the  DP  are 
compatible  with  the  baseline  DP  capability.  However,  the  iteration 
rate  of  the  line  processing  results  in  an  increase  in  the  number  of 
operations  required  during  the  critical  stabilization  function  propagation 
delay  period.  Consequently,  the  DP  throughput  capability  must  be 
increased  to  accommodate  this  peak  load.  The  DP  requirements 


TABLE  22.  DP  REQUIREMENTS  FOR  DATA  LINK,  UR  SEEKER  FUNCTIONS 


THROUGHPUT. 

KOPS 


BUS  rate, 
(words/ tec) 


FUNCTION 

LOCATION 

PROGRAM 

SIZE 

OPERAND 

MEMORY 

SHORT 

LONG 

DATA 

INTERRUPT 

MESSAGE  DECODING 

DP 

10 

5 

8 

0 

270 

30 

DATA 

LINK 

110 

20 

25 

0 

270 

30 

LINE  +  FIELD 

DP 

250 

40 

315 

10.7 

26,200 

800 

FIELD  ONLY 

DP 

215 

40 

28 

11 

1,380 

60 

LINE  +  FIELD 

MR 

20 

-0- 

12 

■0 

240 

60 
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associated  with  HR  field  processing  and  the  discussion  concerning  this 
function  for  Configuration  II  are  also  applicable  to  this  weapon 
configuration. 

7.6.4  Generic  Classes  of  Configuration  Dependent  functions 

The  examples  of  configuration  dependent  processing  functions  dis¬ 
cussed  in  the  preceding  paragraphs  provide  insight  concerning  the 
relationship  between  the  characteristics  of  the  functions  and  their 
effect  on  digital  processor  requirements.  The  characteristics  of  pri¬ 
mary  interest  are  the  function  processing  bandwidth,  computational 
complexity,  and  its  interfaces  with  all  other  weapon  functions. 


The  functions  of  the  weapon  subsystem  can  be  arbitrarily  divided 
into  two  classes  on  the  basis  of  processing  bandwidth,  which  deter¬ 
mines  the  required  iteration  rate  of  the  function  of  it  as  performed  by 
the  digital  processor.  For  the  purpose  of  this  study,  all  functions 
with  an  interation  rate  commensurate  with  or  higher  than  the  stabili¬ 
zation  function  iteration  rate  (400  Hz)  will  be  classified  as  signal  pro¬ 
cessing,  and  the  lower  iteration  rate  functions  will  be  designated  as 
data  processing.  Computational  complexity  is  concerned  with  both  the 
number  of  input  parameters  and  operations  on  these  parameters  which 
are  implied  by  the  function.  The  interface  characteristic  of  primary 
interest  is  the  location  of  the  destination  of  the  function  outputs  relative 
to  the  function  inputs. 


Most  signal  processing  functions  are  characterized  by  relatively 
simple  operations  on  large  amounts  of  data.  The  small  program  size 
and  high  throughput  requirement  exemplified  by  the  E-O  seeker  line 
processing  is  typical  for  performing  this  class  of  function  in  the 
digital  processor.  As  a  result,  the  throughput  capability  of  the  pro¬ 
cessor  may  be  exceeded  due  to  a  combination  of  functional  computa¬ 
tional  complexity  and  software  operations  to  support  data  transfei  o. 
Although  the  major  functional  outputs  of  this  type  of  processing  func¬ 
tion  are  steering  signals  for  flight  control,  a  number  of  parameters 
usually  must  be  sent  back  to  the  data  source  subsystem  to  control  its 
operations,  but  the  principal  effect  on  weapon  bus  capacity  is  the  input 
data  rate. 

Data  processing  functions  usually  involve  relatively  complex 
operations.  The  throughput  requirement  to  perform  this  type  of  fun:- 
tion  in  the  digital  processor  is  generally  small  compared  to  the  total 
for  the  CORE  functions  due  to  the  low  function  iteration  rate.  The 
program  memory  size  requirement  for  this  class  depends  not  only  on 
the  cotirpiilalicn  complexity  th^  «lr;'llirliy  Hi*-  up*  ration*  involved 
in  the  function  to  the  operations  of  the  CORE  functions.  A  relatively 
complex  function  may  have  minimal  program  memory  requirements  if 
existing  subroutines  can  be  used  for  the  function.  Most  candidate  data 
processing  functions  have  a  major  interface  with  the  CORE  functions. 

7.6.5  Weapon  System  Considerations 

Each  configuration  dependent  processing  function  must  pass 
certain  criteria  if  it  is  to  be  performed  by  the  digital  processor.  At 
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the  lowest  level,  only  the  cost  of  implementing  the  function  in  the 
subsystem  versus  the  digital  processor  need  he  considered.  The  sub¬ 
system  cost  tradeoff  must  include  not  only  the  implementation  cost  of 
the  function  itself,  but  also  relative  costs  of  conforming  to  the  standard 
interface  definition.  The  subsystem  cost  differential  must  at  least 
balance  the  cost  of  DP  memory  associated  with  the  function,  assuming 
sufficient  processor  throughput  to  perform  the  function.  Cost  compari- 
sions  of  this  type  are  commonly  used  for  functional  partitioning  in 
point  designs,  but  the  modular  weapon  system  characteristics  require 
additional  criteria. 

Even  in  point  designs,  the  combination  of  all  cost  effective  func¬ 
tions  (determined  on  an  individual  basis)  may  exceed  the  digital  proces¬ 
sor  capability  requiring  additional  tradeoffs  to  determine  the  relative 
cost  of  increased  processor  performance  versus  dropping  some 
desired  functions.  There  are  obvious  problems  in  extending  this  pro¬ 
cedure  to  the  modular  weapon  system.  If  a  function  is  performed  by 
the  digital  processor  in  any  weapon  configuration,  then  the  processor 
must  be  capable  of  performing  the  function  in  all  pertinent  weapon 
configurations  in  addition  to  the  CORE  functions.  The  processor 
requirements  were  established  in  the  previous  subsection  by  applying 
a  growth  factor  in  the  CORE  function  peak  processing  requirements  for 
the  selected  weapon  conligurations.  This  growth  factor  provides  for 
configuration  dependent  variations  in  the  CORE  function  peak  require¬ 
ments  over  all  weapon  configurations.  This  implies  that  a  configura¬ 
tion  dependent  function  which  increases  the  peak  CORE  function  require¬ 
ments  may  not  be  allowed  for  all  weapon  configurations.  Thus,  the 
decision  process  for  each  configuration  dependent  function  must  con¬ 
sider  the  effect  of  that  function  on  CORE  processing  requirements  for 
all  pertinent  weapon  configurations  in  addition  to  the  requirements  for 
the  function  itself.  This  decision  process,  therefore,  involves  the 
evaluation  of  total  processing  requil  eluents  for  all  pertinent  weapon 
configurations  and  requires  that  the  function  fit  within  the  excess  pro¬ 
cessor  capability  after  the  CORE  functions  are  performed  in  each  con¬ 
figuration.  In  general,  only  functions  in  the  data  processing  class  will 
meet  this  criterion. 

The  desirability  of  performing  any  configuration  dependent  func¬ 
tion  should  be  a  function  of  its  differential  implementation  cost 
weighted  by  its  probable  percentage  usage  over  all  weapon  configura¬ 
tions  used.  The  frequency  of  occurrence  of  the  function  is  especially 
important  if  the  processor  contains  software  pertinent  to  all  weapon 
configurations.  A  function  with  large  program  memory  requirements 
which  is  only  pertinent  to  a  small  percentage  of  weapons  would  generally 
t+'quir'i’  a  large  UiLpIi'crimtiLr Lon  real  a.'Jwarjla:yi  pt  r  uai  To  ovrrr'ornr 
added  memory  costs  over  all  configurations. 

No  specific  rviles  or  guidelines  have  been  developed  which  may  be 
generally  applied  to  configuration  dependent  functions.  However,  the 
important  factors  which  must  be  determined  in  the  decision  process 
have  been  discussed. 
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SECTION  VIII 
TECHNOLOGY  STUDY 


This  task  was  concerned  with  using  some  of  the  newer  technologies 
to  implement  the  DP  processing  system.  The  goal  was  to  achieve  the 
DF  pi-rfurin mn  rj'qil  1  fi'iiiertl  with  i  wignifirant  ri-dunion  in  ruAt^  powi  r 
dissipation,  and  size  relative  to  available  digital  processors  today.  In 
particular,  three  technologies  were  to  be  investigated; 

•  Low  power  Schottky  TTL  (LPSTTL) 

•  Silicon- on- sapphire  C-MOS  (SOS  C-MOS) 

2 

•  Integrated  injection  logic  (I  L) 

The  study  focused  on  the  use  of  LSI  devices,  in  one  or  more  of  the 
above  technologies,  to  implement  the  several  DP  functions.  There  are 
several  approaches  to  the  use  of  LSI  in  the  DP  system; 

•  Use  of  commercially  available  LSI  designs 

•  Semicustom  LSI  design  (e.  g.  ,  gate  arrays  or  cell  arrays) 

•  Custom  LSI  design. 

2 

The  SOS  C-MOS  and  I  L  processes  are  still  too  new  to  have  any 
significant  number  of  commercial  LSI  designs  available  or  even  viable 
semicustom  approaches.  Hence,  custom  LSI  approaches  were  con¬ 
sidered  for  these  technologies.  In  the  LPSTTL  process,  on  the  other 
hand,  there  are  available  both  commercial  LSI  design  and  semicustom 
LSI  design  approaches.  Therefore,  the  LPSTTL  investigation  was  con¬ 
fined  to  these  two  approaches. 

LPSTTL  is  the  most  mature  of  three  technologies  and  would  cer¬ 
tainly  be  a  strong  contender  for  implementing  the  DP  system  if  it  were 
to  be  done  today.  There  are  available,  now,  a  fairly  good  selection  of 
LPSTTL  LSI  devices  designed  explicitly  for  computer  or  digital  pro¬ 
cessor  applications.  Among  the  more  interesting  of  these  devices  are 
the  so-called  bit-slice  micro-processor  chips  (also  called  microcon¬ 
trollers  and  various  other  names).  These  are  essentially  a  slice 
through  the  major  functions  of  a  computer  CPU  and  may  be  2  bits  wide 
or  4  bits  wide  at  the  present  time.  Thus  a  single  4-bit  slice  alone 
would  be  a  4-bit  microprocessor.  Eour  of  them  would  form  a  16-bit 
microprocessor.  Typically,  other  devices  need  to  be  added  to  com¬ 
plete  the  CPU  function  or  to  give  better  performance.  Among  the  added 
chips  are  Microprogram  Control  Units  (MCU),  ROMs  for  the  micro¬ 
program,  carry  look  ahead  generators  for  faster  arithmetic,  and  vari¬ 
ous  registers  and  multiplexers.  Using  a  typical  four-bit  microproces¬ 
sor  slice,  a  16-bit  microcomputer  CPU  can  be  built  with  approximately 
20  chips.  While  such  a  processor  cannot  satisfy  the  DP  requirements, 
it  is  far  more  powerful  than  any  available  MOS  microprocess-based 
computer. 
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The  use  of  the  bit-sliced  microprocessors  is  not  limited  to  the 
kind  of  application  described  above.  They  can  be  used  in  more  power¬ 
ful  designs  by  adding  additional  peripheral  devices  and/or  paralleling 
functions.  By  these  techniques  a  processor  satisfying  the  DP  require¬ 
ments  can  be  built.  This  was  the  goal  of  the  DP-X  design  study  reported 
herein. 

8.  1  DP-X  DESIGN  STUDY 
8.1.1  Design  Approach 

The  purpose  of  the  DP-X  design  study  was  to  design  a  digital  pro¬ 
cessor  that  satisfies  the  DP  requirements  and  uses  available  LSI, 
LPSTTL,  bit-slice  microprocessors.  The  DP-X  design  will  be  com¬ 
pared  to  other  approaches  in  the  cost  analysis  study  to  determine  how 
successful  chis  approach  is. 

The  general  performance  requirements  are  given  below  along  with 
some  rather  general  gound  rules. 

DP-X  PERFORMANCE  REQUIREMENTS 

•  16  bit  fixed  point 

•  2  8K  program  memory  address 

•  2  4K  data  memory 

•  >2  arithmetic  registers 

•  2  16  index  registers 

•  2  32  level  pushdown  stack 

•  2  2.8  MIPS  (short  equivalent) 

•  Block  transfers 

•  -180  instructions 

•  Satisfy  DP  interrupt  procedures 

DP-X  Design  Study  Ground  Rules 

•  Modular  design 

•  Minimize  power  consumption 

•  Minimize  size 

This  task  was  undertaken  to  show  that  with  low  power  Schottky 
(LPS)  circuits,  a  near  term  design  can  be  implemented  that  establishes 
the  validity  and  practicability  of  the  proposed  specification.  To  achieve 
performance  comparable  to  higher  powered  circuits  with  the  low 
powered  circuits,  increased  parallel  processing  (i.  e.  ,  pipelining)  is 
required.  Larger  scale  integration  is  required  to  reduce  component 
package  count.  Modularity  is  necessary  to  prevent  premature  obsoles¬ 
cence  and  to  allow  continued  update  of  hardware  modules  without 
changes  in  software. 
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The  DP-X  design  is  carried  only  to  a  point  sufficient  to  count 
cycle  times  of  various  instruction  types  and  understand  programming 
implications.  This  baseline  design  also  provides  mechanical  packag¬ 
ing  information  so  that  realistic  manufacturing  cost  and  physical  size 
can  be  determined. 

8.1.2  Instruction  Formats 

factor  in  any  processor  design  is  the  instruction  format, 
ith  increasing  recognition  of  software  development  and  maintenance 
costs,  an  easily  understood  and  usable  format  is  very  important.  With 
so-called  standardization  more  frequently  heard,  a  popular  format 
might  have  some  side  benefits.  Another  assumption  is  that  with  ROM 
density  increasing,  small  differences  in  program  memory  size  may 
not  be  a  significant  factor  in  the  1980's. 

A  number  of  formats  were  examined  including  the  ones  in  DP  I 
and  II.  The  basic  decision  to  be  made  was  whether  to  use  a  fixed 
instruction  word  length  or  a  variable  word  length.  By  stringent  adher¬ 
ence  to  the  minimum  requirements  the  operations  code  requires  8  bits; 
arithmetic  register,  1  bit;  index  register,  4  bits;  memory  address, 

13  bits;  with  a  total  of  26  bits.  This  also  allows  no  expansion  in  mem¬ 
ory  size  beyond  8000  words,  except  by  paging.  A  variable  instruction 
format  such  as  IBM  or  Interdata  shown  in  Figure  53,  which  consists 
of  either  16  or  32  bits,  is  very  popular.  The  break  even  point  in 
efficiency  between  fixed  and  variable  format  occurs  where  62  percent 
of  the  instructions  are  32  bits;  beyond  that  the  variable  format  requires 
more  program  bits.  The  variable  format,  however,  allows  almost 
unlimited  memory  expansion  as  far  as  missile  requirements  is  con¬ 
cerned,  and  also  has  the  happy  coincidence  of  each  16  bits  correspond- 
mg  to  the  data  word  length  of  16  bits,  a  convenience  in  system  layout. 
Therefore,  the  variable  word  length  was  adopted.  An  attempt  was 
rnade  to  use  the  exact  Interdata  instruction  set  so  as  to  take  advantage 
of  existing  software  support.  This  appeared  to  be  impractical  for 
missile  applications  because  too  many  compromises  must  be  made. 

The  final  set  adopted,  as  shown  in  Figure  54,  actually  includes  the' 
Interdata  format.  A  third  register  field  is  added  to  the  address  por¬ 
tion  optionally  so  that  by  not  using  that  field,  it  reverts  to  the  Inter¬ 
data  format.  Greater  flexibility  and  versatility  can  be  achieved  in 
instruction  formating.  The  4-bit  register  fields  in  these  instruction 
formats  happen  to  fit  the  4-bit  LSI  arithmetic  logic  units,  ALUs,  now 
becoming  available  from  more  than  one  vendor.  With  appropriate 
multiplexing  circuits  and  microprogramming  control,  implementation 
of  Interdata  instruction  set  is  also  possible.  The  new  4-bit  ALUs  have 
16-word  internal  registers.  The  match  with  the  4-bit  register  field  is 
perfect.  This  allows  the  use  of  one  set  of  ALUs  with  16  general  pur  - 
pose  registers  or  two  sets  of  ALUs  with  16  arithmetic  and  16  index 
registers  separately.  For  speed  reasons,  two  sets  of  ALUs  are 
required. 

There  are  two  popular  and  almost  comparable  4-bit  slices  on  the 
the  AMD  2901  and  the  MM  6701.  They  differ  only  in  the 
instruction  format.  The  AMD  2901  allows  a  three  address  operation 
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Figure  53,  IBM  and  Interdata  Formats 


INSTRUCTION  ADDRESS  OR  CONSTANT 
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R  ARITH  REGISTERS  0  15 
X  INDEX  REGISTERS  0  15 
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Figure  54.  DP-X  Instruction  Format  Includes  Inter  data  or  IBM  Format 


the  way  the  macro- instruction  set  is  configured  whereas  the  MM  6701 
does  not.  For  this  reason,  the  AMD  2901  was  chosen  as  a  nominal 
part  for  this  design  exercise. 

8,1.3  Typical  Instructions 

The  3-register  address  format  is  illustrated  to  demonstrate  its 
versatility  (Figure  55).  First  are  the  short  instructions  of  one  word 
(16-bits)  which  may  be  register-to- register  (R  for  arithmetic  and  X 
for  index  registers),  or  register  and  a  short  constant  (S),  For  the 
long  instructions,  the  next  word  is  an  immediate  const3.nt  (I),  an 
address  (A)  or  a  register  field  (X)  and  an  address  (A).  In  the  last  case, 
only  12  bits  of  address  are  available  but  the  index  register  has  16  bits, 
so  the  total  range  is  still  16  bits.  Another  useful  type  of  instructions 
is  the  tra  ifris-  Hero  the  S  field  may  be  the  number  of  words, 

Xi  may  be  the  beginning  register  location,  and  X3,  A  are  the  indexed 
memory  addresses.  This  type  is  highly  desirable  where  frequent 
interrupts  occur  and  registers  must  be  preserved  for  later  resumption 
of  interrupted  routines. 

In  view  of  the  separate  ALUs  used,  two  different  sets  of  arithmetic 
instructions  are  required.  In  this  construction,  the  index  arithmetic 
■  is  designed  to  be  integer  and  the  real  arithmetic  fractional, 

8.1.4  DP-X  Units  and  Buses 

DP-X  (FigaVc  56)  is  organised  in  modular  fashion  sc  that  data  fol¬ 
lows.  the  pipeline  structure  to  achieve  the  speed  required.  There  are 
two  almost  identical  arithmetic  units  (can  be  made  completely  identi¬ 
cal),  one  for  indexing  and  the  other  for  regular  arithmetic,  with  their 
respective  register  fields.  Each  arithmetic  unit  has  complete  micro¬ 
program  control  so  that  it  is  only  necessary  to  pass  from  one  to  the 
other  the  undecoded  operation  code  and  the  requisite  register  fields. 
Interrupt  is  shown  as  a  separate  unit,  but  is  actually  packaged  together 
with  the  memory  controls  and  other  miscellaneous  control  circuits. 

I  he  I/U  as  shown  is  inlended  to  be  that  pc-rtioT.  cl  the  V.'US  iiitclfface  Unit. 
It  is  assumed  to  tie  in  the  data  memory  bus,  but  can  be  tied  to  any  other 
bus  if  more  convenient. 

8.1.5  DP-X  Pipeline 

The  pipeline  flow  (Figure  57)  starts  with  the  program  address  con¬ 
trol  where  either  the  next  program  word  is  set  up  or  a  branch  address 
is  used.  This  address  fetches  the  word  in  program  memory.  The 
first  one  is  always  an  operation  code,  which  goes  to  the  operations 
register  (OPR).  The  next  word  goes  to  the  address  or  constant  regis¬ 
ter  (IXAR),  and  may  be  an  address  or  constant,  or  may  be  another 
operation  code.  In  the  latter  instance,  the  content  in  IXAR  is  simply 
ignored,  and  on  the  next  cycle  the  same  information  is  read  into  the 
OPR.  The  code  in  OPR  is  decoded  through  the  microprogram  control 
j^0j^-^Qry,  and  the  control  information  then  is  available  in  the  pipeline 
register  simultaneously  with  the  address  availability  in  IXAR, 
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Figure  57.  DP-X  Pipeline 

The  arithmetic  chips  in  ALU  X  then  take  two  cycles  to  complete  a 
short  arithmetic  or  simply  passing  it  through.  In  most  cases,  this  is 
the  address  for  the  data  memory,  which  takes  one  cycle  to  fetch  the 
data.  Simultaneously,  the  operations  code  and  register  addresses  are 
passed  along  to  ALU  R  so  that  when  the  data  becomes  available,  the 
microprogram  control  information  for  ALU  R  is  also  available.  In 
another  two  cycles,  ALU  R  finishes  its  operation  and  if  the  output  is  to 
be  stored  in  memory,  it  is  deposited  in  the  data  write  register  (DWR). 
Previously,  the  address  from  ALU  X  was  in  data  read  address  register 
(DARR);  it  is  passed  along  to  data  write  address  register  (DAWR)  so 
that  the  information  for  writing  into  the  data  memory  is  again  available 
at  the  same  time. 

For  most  short  arithmetic  instructions,  two  cycles  are  all  that  is 
necessary.  For  multiplications,  handshake  logic  stops  the  pipeline 
until  the  ALU  can  again  handle  the  next  instruction.  For  branches,  the 
pipeline  is  stopped  if  and  when  an  irrevocable  operation  is  about  to  be 
performed,  which  may  be  in  the  wrong  branch.  For  that  reason,  if 
branch  is  to  be  effected,  it  sometimes  takes  one  or  more  cycles  to  be 
completed  in  addition  to  the  regular  two  cycles.  This  can  be  shortened 
by  one  cycle  if  a  small  amount  of  hardware  is  added  to  recognize  cer¬ 
tain  branches. 


The  length  of  the  pipeline  is  further  illustrated  by  the  timing  chart 
(Figure  58).  A  span  of  8  cycles  is  possible.  It  should  be  noted  that 
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Figure  58,  Normal  Cycle 


each  cycle  is  basically  a  memory  access  time  plus  certain  register 
and  multiplexer  delays.  For  bipolar  memories  and  low  power  Schottky 
register  circuits,  it  is  estimated  that  for  worst  case  military  tempera¬ 
tures  of  IZS'C,  a  cycle  time  of  150  to  175  nanoseconds  should  be 
allowed  if  the  faster  bipolar  ROM  or  RAM  are  used. 

The  arithmetic  chips  have  a  cycle  time  slightly  longer  than  the 
projected  memory  access  times.  Certain  status  bit  transmission  time 
through  the  control  circuits  must  also  be  allowed  for  branch  or  other 
control  decisions.  The  arrangement  of  using  two  memory  cycles  for 
one  arithmetic  cycle  is  a  sufficient  build-in  safety  factor.  On  the  other 
hand,  it  is  possible  to  increase  the  multiplication  or  division  speed  by 
adding  a  faster  clock  cycle  by  adding  more  circuits.  If  really  high 
speed  multiplication  is  necessary,  a  serial- parallel  multiplexer  appears 
to  be  practicable,  but  is  not  considered  in  the  present  baseline  design. 

8.1.6  Program  Control 

Figure  59  illustrates  DP-X  program  control.  The  basic  element 
in  program  control  is  the  program  address  counter  (PAG).  Parallel 
load  of  this  counter  via  a  multiplexer  effects  the  various  branch  modes, 
including  interrupt.  For  return  to  subroutine  only,  a  256  address 
stack  is  provided  to  avoid  timing  conflicts  with  the  data  memory.  No 
facility  for  end  of  stack  is  provided  because  of  the  apparent  infinite 
depth. 

Not  directly  related  to  program  control  are  the  handshake  logic  for 
the  two  ALUs,  The  basic  principle  is  to  determine  the  state  of  readi¬ 
ness  to  transmit  and  receive  of  succeeding  units  in  the  pipeline 
organization. 
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Figure  59.  Program  Control 


The  basic  clock  of  nominally  25  MHz  is  divided  down  one  to  four  to 
provide  a  system  clock  pulse  of  25  percent  duty  cycle.  This  is  farther 
divided  down  a  factor  of  two  to  provide  the  A  and  B  clock  pulses  of  the 
two  ALUs,  whose  cycles  are  staggered  one  system  clock  time.  High 
powered  Schottky  circuits  are  used  in  the  clock  distribution  system  to 
effect  minimum  clock  skew  between  different  circuits. 

The  address  processor  (ALUX),  shown  in  Figure  60,  is  representa¬ 
tive  of  the  two  ALUs  ar  d  is  the  more  complicated  one.  The  program 
data  bus  splits  to  OPR  and  IXAR.  The  OPR  is  part  of  a  simple  micro¬ 
program  control  built  with  ordinary  multiplexers.  Available  sequence 
controls  were  found  to  be  not  too  suitable  because  features  such  as 
stacks  are  not  too  useful  in  a  high  speed  machine  where  steps  are  mini¬ 
mized.  Necessary  features  such  as  branch  address  input  multiplexing 
are  not  always  available.  Some  high  powered  (logically)  sequence  con¬ 
troller  chips  have  awkward  addressing  arranpments  that  waste  control 
memory  space  and  some  multiplication  and  division  control  features 
are  not  directly  usable.  A  more  appropriate  sequence  controller  is 
described  later. 

The  16-word  registers  in  the  ALU  chips  dictate  the  systern  design 
to  a  considerable  extent.  In  view  of  the  still  limited  number  of  regis¬ 
ters,  each  time  an  interrupt  occurs  a  number  of  registers  must  be  pre¬ 
served  for  later  resumption.  This  is  anticipated  with  the  block  trans¬ 
fer  instructions. 


8.1.7  Comparison  of  DP- 1  and  DP-X  Speeds 

A  few  selected  passages  of  DP- 1  program  were  checked  on  DP-X 
by  trial  programming.  Results  are  shown  in  Figure  61.  The  message 
parameter  update  module  is  branch  intensive.  The  task  queue  dispatch 
is  block  transfer  intensive  and  the  filter  routines  are  computation 
(especially  multiplication)  intensive.  The  time  ratios  reflect  the  advan¬ 
tages  and  limitations  of  DP-X.  The  time  ratios  w'ere  computed  using 
the  pe a s iiiiistic  Dmic  oi  I76  nanoseconds,  it  tne  more  optimistic  limit 
of  150  nanoseconds  is  used,  the  ratios  become,  respectively,  1.08 
1.43,  1.1,  and  0.93. 

8.1.8  DP-X  Packaging 

Since  the  address  processor  is  the  most  complicated  unit,  it  was 
selected  as  an  example  in  packaging  layout.  Dual- in- line  on  multiple 
Is^ycr  printed  circuit  board  was  tried,  but  it  quickly  became  evident 
that  both  cost  and  size  are  unacceptable.  Hybrid  packaging  yielded 
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satisfactory  package  size,  but  the  integration  of  so  many  high  level 
chips  in  a  partially  tested  fashion  introduces  rework  problems  not 
completely  predictable  at  this  time.  The  last  scheme  tried  appeared 
to  be  the  most  satisfactory.  This  is  the  packaging  of  each  chip  in 
square  leadless  chip  carriers,  of  which  3M  is  the  principal  manu¬ 
facturer.  These  leadless  chip  carriers  are  used  in  large  quantities 
for  commercial  products.  They  are  much  smaller  than  comparable 
dual- in-line  packages,  and  are  designed  for  reflow  solder  onto  ceramic 
circuit  boards.  A  multiple  layer  ceramic  board  is  envisioned  and  is 
also  available  from  the  same  manufacturers.  The  density  is  adequate, 
comparable  by  hybrid  packaging,  and  the  ability  to  individually  burn- in 
and  thoroughly  test  each  component  prior  to  assembly  is  an  important 
advantage.  The  cost  of  the  leadless  frame  is  comparable  to  equivalent 
hermetic  dual-in- line  packages,  and  may  be  even  slightly  lower.  For 
this  reason,  switching  by  industry  to  such  a  package  or  equivalent  is 
probably  inevitable  when  high  level  integration  with  their  many  pinouts 
becomes  commonplar3. 

Figure  62  illustrates  the  DP-X  address  processor  in  its  proposed 
packaging. 

The  method  of  attaching  a  heat  sink  to  the  multilayer  ceramic  board 
has  gone  through  several  iterations.  The  adopted  concept,  shown  in 
Fieure  63,  is  to  attach  the  board  to  the  heat  sink  and  mount  the  connec¬ 
tor  to  the  heat  sink,  similar  to  the  SEMS  approach.  The  beat  sink  then 
provides  the  mechanical  connection  (and  heat  path)  to  the  interconnec¬ 
tion  plane.  The  heat  sink  also  includes  screw  jacking  arrangements 
for  securing  the  board  and  for  its  removal  in  a  controlled  way.  The 
force  on  the  large  connector  is  considerable  and  is  not  carried  by  the 

ceramic  board. 
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Figure  62.  Advanced  DP  Address  Processor 
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not  comparable  to  full  LSI  custom  designs.  It  should  be  noted  that  the 
cell  array  approach  used  elsewhere  in  estimating  BIU  circuits  has  not 
been  applied  to  the  CPU.  A  factor  of  4  to  6  component  count  reduction 
may  be  expected  in  CPU  if  cell  arrays  are  used. 

A  summary  of  DP-X  characteristics  follows: 

Low  power  Schottky  (mostly) 

Z  ALUs:  ALU  X  integer  arith  and  address 
ALU  R  fraction  arith 
~2.  5  MIPS  short  instructions 
~30  W  ALUs  and  memory  control 
16  registers  each  ALU 
Pipeline  organization 
Standard  instruction  format 

Leadless  carrier  and  multilayer  ceramic  boards 

193  ICs  on  3  boards  (164  can  be  reduced  with  cell  arrays) 

8.  2  LOW  POWER  SCHOTTKY  CELL  ARRAY  TECHNOLOGY 

There  are  several  semicustom  design  approaches  available  in  low 
power  Schottky.  Gate  arrays  have  been  available  for  several  years. 

In  this  approach,  a  standard  chip  with  several  hundreds  of  unconnected 
gates  is  processed.  An  LSI  circuit  is  created  by  interconnecting  the 
gates  with  one  or  more  layers  of  metalization.  A  somewhat  different 
approach  to  semicustom  LSI  was  examined  in  this  study.  It  is  called 
cell  array  semicustom  LSI.  In  this  approach,  the  basic  building  blocks 
are  standard  MSI  functions  rather  than  gates.  The  designer  has  avail¬ 
able  a  library  of  standard  functions  (such  as  registers,  multiplexers  or 
a  set  of  buffers).  Up  to  ten  of  these  cells  can  be  placed  on  a  single  chip 
to  create  an  LSI  circuit.  (The  upper  limit  of  number  of  cells  per  chip 
is  determined  primarily  by  yield  considerations.  )  The  designer  has 
freedom  with  respect  to  selection  of  cell  types  and  relative  position  of 
cells.  Interconnection  is  by  up  to  three  layers  of  metalization.  The 
cell  array  approach  has  a  rapid  turnaround  time:  about  12  weeks  for 
design  and  processing.  Cost  studies  show  that  acquisition  costs  are 
about  the  same  as  (or  a  little  more  than)  buying  the  equivalent  discrete 
MSI  chips.  However,  overall  costs  tend  to  be  lower  because  of 
decreased  assembly  labor.  Moreover,  a  significant  saving  in  board 
area  is  accomplished. 

The  cell  array  approach  was  applied  to  the  design  of  the  bus  inter¬ 
face  unit  to  examine  its  potentialities.  The  basic  cell  library  used  was 
that  created  by  Hughes,  Newport  Beach.  One  new  cell  design  was 
needed:  an  array  of  differential  line  receivers  and  drivers.  The  exist¬ 
ing  circuitry  for  the  three  cards  (slave,  interrupt  and  bus  race)  was 
partitioned  into  nine  cell  array  chips.  The  only  circuits  not  placed  in 
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the  cell  arrays  were  the  proms.  With  this  approach,  the  three  BIU 
cards  can  easily  be  packaged  on  a  3x4-inch  ceramic  circuit  board. 

(It  was  assumed  that  the  chips  were  placed  in  64  pin  leadless  carriers.) 

This  technology  could  also  be  applied  to  the  DP-X  CPU.  Of  the 
1  (3  ICs  used  in  thai  dtsign,  164  (“OiiJd  b'l"  r a r tnl  with  ct'll  arrays  K> 
achieve  a  reduction  in  chip  number  by  a  factor  of  4  to  6.  This  would 
probably  eliminate  one  circuit  board. 

The  LSI  cell  arrays  were  also  used  in  the  I/O  design  and  other 
circuitry  in  the  six  configurations  of  the  cost  analysis. 

A  photograph  of  a  4-cell  array  is  shown  in  Figure  64.  The  results 
of  the  study  indicate  that  this  technology  can  be  useful  in  the  DP  applica¬ 
tion  for  I/O  and  other  peripheral  circuits. 

8.  3  SOS  C-MOS  LSI  TECHNOLOGY 

Silicon-on- sapphire  (SOS)  technology  significantly  improves  the 
performance  of  MOS  circuits.  The  isolation  achieved  by  the  sapphire 
reduces  stray  capacitance  which  allows  improvements  in  both  speed  and 
density.  It  is  now  known  that  a  high  performance,  16  bit  CPU  on  a  sin¬ 
gle  chip  can  be  achieved.  An  example  is  the  Hughes  SOS  C-MOS  pro¬ 
cessor  which  is  illustrated  in  Figure  65.  This  processor  had  a  design 
goal  of  0.  5  microsecond  for  add  time  and  3  microseconds  for  multiply. 
Preliminary  tests  on  the  processed  chips  indicate  that  the  performance 
will  not  be  too  far  off  from  the  goal.  It  should  be  noted  that  achieving 
this  kind  of  performance  is  not  a  straightforward  matter  with  the  SOS 
C-MOS  process.  The  circuit  and  logic  design  required  to  achieve  the 
high  speed  are  considerably  different  from  those  normally  encountered 
using  discrete  parts.  For  example,  in  the  present  design,  it  was 
desired  to  obtain  a  fast  multiply  to  match  the  requirements  for  many 
missile  applications.  Because  of  the  relatively  slow  MOS  circuits, 
this  was  not  possible  without  resorting  to  a  carry- save  multiply  circuit. 
The  conclusion  is  that  a  rather  high  performance  processor  can  be 
achieved  with  SOS  C-MOS,  but  only  by  exercising  a  great  deal  of  care 
in  the  initial  logic  design  and  the  circuit  design  and  layout.  There  must 
be  a  considerable  amount  of  interaction  between  these  phases,  i,  e.  ,  the 
logic  design  must  look  ahead  to  the  circuit  problems  that  will  be  encoun¬ 
tered  in  trying  to  get  the  desired  high  performance. 

It  is  believed  that  the  performance  goal  of  the  Hughes  SOS  C-MOS 
processor  is  close  to  what  can  be  obtained  with  the  process.  In  fact, 
the  goal  should  probably  be  relaxed  somewhat  to  give  more  design  mar¬ 
gin.  It  would  appear,  then,  that  the  SOS  C- MOS  technology  can  probably 
not  produce  a  single  chip  processor  that  will  satisfy  the  DP  requirement. 
However,  it  does  appear  that  the  requirement  can  be  met  with  a  multi¬ 
chip  design.  One  approach  would  be  a  multiprocessor  using  two  or 
more  CPU  chips  similar  to  the  one  described  above.  This  approach 
was  uSe-d  far  oUx.  cf  the  configurations  in  the  cost  aaaly&is. 
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Figure  65.  SOS-CMOS  (SOCM)  Processor  Internal 
and  External  Elements 


8.4  I^L  TECHNOLOGY 

Perhaps  the  most  promising  of  the  new  technologies  is  integrated 
iniection  logic  (I^L).  The  potentialities  of  this  process  (not  yet  achieved 
in^production)  include  a  power  dissipation  in  the  MOS  range  but  speed 
in  the  bipolar  range.  Moreover,  the  circuit  design  process  is  sirnpler 
than  with  SOS  C-MOS  since  the  effects  of  stray  capacitance  are  not  so 
devastating. 

The  technology  is  still  rapidly  evolving,  and  there  would  seern  to 
be  as  many  different  I^L  processes  as  there  are  researchers  working 
on  it.  Improvements  added  to  the  basic  process  include  one  or  more 
Schottky  diodes  added  to  the  gate  input  or  output  to  increase  speed. 

I^L  is  the  most  likely  of  today's  technology  to  obtain  a  DP -type  pro¬ 
cessor  on  a  single  chip. 

To  explore  the  possibilities  of  the  process  for  DP,  a  test  design 
was  made.  It  was  noted  before  that  none  of  the  microprocessor  control 
units  (MCU)  on  the  market  meet  the  high  speed  requirements  of  DGW  i 
processor  design.  Most  available  chips  emphasize  the  looping  or 
Lbroutine  stacking  requirements  in  micro-program  and  most  fre¬ 
quently  ignore  the  branching  input  multiplexing  requirements.  In 
highly  pipelined,  high  speed  computer  design,  the  objective  ts  to  reduce 
the  number  of  microprogram  steps  to  a  minimum  (one)  in  each  ALU. 
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Another  frequently  ignored  feature  for  high  speed  arithmetic  are  the 
shift  controls  and  decision  inputs  required  for  multiplication  and  divi¬ 
sion.  All  the  above  functions  are  available  in  one  chip  or  another,  but 
not  in  the  same  chip.  As  a  result,  the  selection  of  any  available  LSI 
MCU  chips  does  not  materially  reduce  the  chip  count,  but  frequently 
suffers  in  speed  because  of  the  need  to  serially  stack  multiplexing  cir¬ 
cuits  external  to  the  control  chip,  in  addition  to  those  already  existing 
internally. 

A  design  was  defined  (Figure  66)  that  is  more  suited  to  the  short 
microprogram  sequences  encountered  in  DGWT  type  high  speed  com¬ 
puters.  The  branch  address  and  instruction  entering  address  ports  are 
equally  treated  so  that  the  two  parts  can  act  independently  in  a  pipeline 
organization.  In  addition,  a  subroutine  return  register  allows  a  one 
level  subroutine,  which  is  quite  adequate  in  the  DP  design.  An  addi¬ 
tional  register  for  the  next  address  allows  larger  flexibility  in  using 
the  branch  address.  Decoders  and  control  bit  registers  complete  the 
design. 

A  cell  library  approach  was  taken  for  the  chip  design.  A  stan¬ 
dard  D  register  was  modified  so  that  s  slice  of  the  four-way  multiplexer 
is  included  to  allow  easier  interconnections.  (It  should  be  noted  that  the 
two  levels  of  metal  interconnection  available  greatly  facilitate  the  chip 
layout.  )  This  basic  cell  is  used  more  than  40  times  in  the  MCU  chip 
for  a  lO-bit  chip  organization. 


Figure  66,  MCU  Chip 
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8.  5  TECHNOLOGY  CONCLUSIONS 

The  fact  that  most  microprogram  control  unit  chips  on  the  market 
are  not  very  suitable  for  high  speed  computer  organizations  points  out 
that  as  level  of  integration  increases,  less  commonality  between  dif¬ 
ferent  users  can  be  found.  A  highly  integrated  computer  chip  for  mis¬ 
siles  may  not  necessarily  find  general  use  in  fields,  tnd 

the  reverse  is  probably  also  true. 

Since  the  available  4-bit  ALU  chips  strongly  influence  DP-X 
organization  including  instruction  format,  the  corollary  is  that  a  highly 
integrated  custom  missile  processor  probably  would  not  have  the  same 
organization  as  DP-X  for  optimum  utilization  of  a  particular  technology. 

From  designs  already  completed  at  Hughes  using  SOS-CMOS  tech¬ 
nology  for  a  16-bit  missile  processor  and  the  layout  study  of  the  MCU 
with  the  newer  I^L  process,  it  can  be  extrapolated  that  either  process 
can  be  useil  in  mechanizing  a  fully  integia.ttJ  DP,  with  Vast  reduetio.-i 
in  chip  count. 

Significant  conclusions  of  the  technology  study  are: 

•  Present  LP-STTL  could  yi-dld  adequate  DP 

•  MSI  4-bit  ALU  chips,.with  16  registers  dictates  DP-X 
organization 

•  No  available  MCU  chips  are  completely  suitable 

•  Lengthy  pipelining  cannot  completely  make  up  for  low  speed 
components 

2 

•  LSI  I  Ii  (or  SOS-CMOS)  could  make  processor  much  smaller 

•  Optimum  LSI  processor  design  is  most  probably  different 
from  DP  X 

•  Cell  arrays  can  significantly  reduce  package  count  and  cost 
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SEC  TION  IX 
COST  ANALYSIS 


9.  1  INTRODUCTION 

In  the  course  of  the  system  design  studies,  numerous  design 
decisions  were  made.  In  most  of  these  decisions  cost  was  a  factor. 

In  many  of  these  cases,  the  cost  implications  were  clear  enough  that 
no  detailed  cost  analysis  was  attempted;  in  such  cases  engineering 
judgement  and  experience  was  sufficient  to  settle  the  issue.  The  more 
important  of  this  kind  of  decision  were: 

(1)  The  total  digital  processing  load  in  the  weapon  should  not  be 
concentrated  in  a  single  processor  (i,  e.  ,  it  should  be  distributed 
among  several  processors). 

(2)  A  digital  bus  rather  than  an  analog  harness  should  be  used. 

(3)  The  bus  should  be  a  serial  rather  than  parallel  bus. 

The  subsystem  analysis  studies  showed  that  a  number  of  the  sub- 
systerr.s  had  functions  v/hich  could  (and  should)  be  perfom.ed  digitally. 
Two  examples  studied  in  detail  were  the  E/O  seeker  and  the  radio- 
meteric  area  correlation  (RAC)  sensor.  In  both  cases  there  is  (or 
could  be)  a  significant  digital  processing  load.  Trying  to  centralize 
such  processing  had  one  or  both  of  the  following  effects:  excessively 
high  transmission  rates  on  the  bus;  or  unrealistically  high  throughput 
requirements  for  the  DP.  Moreover,  putting  these  functions  into  a 
central  DP  did  not  significantly  enhance  the  integration  function.  In 
cases  like  this,  the  decision  was  made,  based  on  engineering  judge¬ 
ment  and  experience,  that  well  localized  functions  requiring  high  bus 
rates  or  high  processor  throughput  should  not  be  centralized.  Thus, 
the  DP  design  is  basically  a  distributed  processor  system. 

Having  decentralized  seeker  and  sensor  processing,  there  remains 
a  residue  of  tasks  that  appear  appropriate  to  the  DP  integration  role. 
These  are  the  core  functions,  and  either  are  directly  concerned  with 
integration  or  are  basic  to  most  or  all  of  the  weapon  configurations. 

A  specification  has  been  made  for  the  required  performance  for  the 
DP  digital  processing  system  to  perform  the  core  function  (with 
adequate  growth).  At  this  point,  the  question  again  comes  up  as  to 
the  best  configuration  to  implement  the  requirements.  That  is,  should 
the  core  function  be  distributed  among  two  or  more  processors  or 
should  it  be  centralized?  How  should  the  DP  be  designed:  monopro¬ 
cessor  or  multiprocessor?  In  contrast  to  the  case  with  the  overall 
system,  there  are  several  configurations  that  appear  practical  and  it 
is  difficult  to  make  a  priori  judgements  about  the  relative  cost.  Most 
of  the  questions  have  to  do  with  the  digital  processor(s)  and  not  the 
bus  structure.  That  is,  most  of  the  practical  configurations  have 
approximately  the  same  bus  requirements. 


125 


The  question  of  distributed  versus  central  processing  has  taken  on 
a  new  interest  lately  because  of  the  wide  selection  of  microprocessors 
available.  In  fact,  one  of  the  major  questions  before  the  digital 
designer  these  days  is  how  to  effectively  use  the  various  micropro¬ 
cessors.  The  function  performed  by  the  microprocessor  does  not 
represent  the  majority  of  the  complexity  in  the  total  digital  processing 
system.  Memory,  I/O  and  bus  circuitry  account  for  most  of  it.  Yet, 
the  choice  of  the  way  one  chooses  to  implement  the  CPU  function  can 
effect  the  whole  system.  For  example,  if  one  chooses  to  use  an  MOS 
microprocessor  CPU,  one  is  forced  to  some  kind  of  distributed  pro¬ 
cessing.  Therefore,  one  way  of  examining  the  different  configurations 
is  by  examining  the  different  approaches  to  CPU  implementation. 

Today  there  are  four  major  appr  jaches  to  CPU  in’tpl-eixicntaiion: 

1.  Discrete  MSI  chips 

2.  Bipolar  LSI  microprocessor  chip  sets 

3.  MOS  microproces  sor  s 

4.  Custom  LSI  designs. 

The  last  choice  would  be  essentially  a  custom  microprocessor. 

An  approach  using  a  custom  LSI  design  differs  from  approaches  two 
and  three  in  that  in  the  latter  case,  the  system  is  designed  around  an 
existing  CPU.  In  the  former,  the  CPU  is  designed  to  satisfy  system 
requirements. 

The  cost  analysis  study  focussed  on  the  cost  differences  between 
several  practical  overall  architectures  which  could  satisfy  the  DP 
requirements.  The  basic  question  was  central  versus  distributed. 
However,  subsidiary  questions  were  examined  also:  Monoprocessor 
versus  multiprocessor,  and  MSI  versus  LSI.  In  the  latter,  the  LSI 
refers  to  the  CPU  function.  In  all  the  cases  considered,  it  refers  to 
a  microprocessor,  whether  bipolar  or  MOS,  commercial  or  custom. 
Variations  in  bus  design  were  not  deemed  important  in  deciding  the 
above  question.  Therefore,  the  same  bus  design  was  used  in  all 
configurations  studied. 

Maintenance  costs  and  reliability  were  not  explicitly  treated  in 
the  study,  in  all  of  the  variations  considered,  we  are  dealing  with 
essentially  the  same  kind  of  components  which  are  subjected  to  the 
same  environment.  Under  these  conditions,  reliability  is  largely  a 
function  of  the  number  of  components  involved.  The  number  of  com¬ 
ponents  for  each  variation  studied  is  given  in  the  test.  There  does 
not  appear  to  be  any  significant  differences  in  maintenance  costs  for 
the  different  configurations  studied.  Each  configuration  has  the  same 
number  of  boxes  and  cables.  While  the  number  of  circuit  boards 
varies  across  the  configuration,  this  would  not  seem  to  have  a  major 
effect  on  maintenance  costs.  Another  factor,  which  probably  has 
little  significance  overall,  is  related  to  changing  system  memory. 

In  the  distributed  processor  cases  (with  several  memory  locations) 
there  is  more  labor  involved  in  changing  memory.  It  is  not  expected 
that  memory  will  be  changed  enough  to  make  this  an  important  factor. 
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The  study  reported  in  the  following  pages  conside 
•  Development  costs 


rs 


•  Production  costs 

•  Development  risks 


Software  generation 


for  six  different  architectural  configurations. 


Note  that  the  production  cost  figures  given  in  this  report  are  lower 
than  given  in  the  interim  report.  This  is  because  of  a  reevaluation  of 
material  costs,  and  in  particular  to  extrapolating  all  costs  to  1980.  In 
the  interim  report  only  the  integrated  circuit  costs  were  extrapolated. 


9.2  SELECTION  OF  PROCESSOR  TYPES  FOR  COST  ANALYSIS 


Perhaps  the  most  basic  tradeoff  in  the  cost  analysis  is  central 
versus  distributed  processing.  To  investigate  this  question  adequately 
requires  looking  at  several  other  tradeoffs:  (1)  monoprocessor  versus 
multiprocessor:  (2)  commercially  available  designs  versus  custom 
designs;  and  (3)  the  use  of  LSI  versus  MSI.  The  possible  permutations 
on  these  choices  would  lead  to  16  different  designs.  However,  some 
of  the  designs  are  not  interesting,  are  impractical,  or  give  redundant 
information.  Six  configurations  were  chosen  for  the  study.  Figure  68 
shows  a  decision  tree  which  illustrates  the  chosen  variations. 


point  A  in  Figure  68  represents  the  primary  trade- 
off.  The  branch  at  the  next  level  is  between  monoprocessors  and 
multiprocessors.  A  multiprocessor  is  an  interesting  enough  concept 
to  deserve  inclusion  in  the  study.  (A  multiprocessor  consists  of  two 
or  more  CPUs  working  against  a  common  memory.  )  However,  the 
prime  reason  for  including  it  here  is  the  existence  of  microprocessor 
designs  that  can  be  or  must  be  used  this  way  if  they  are  to  satisfy  the 
DP  requirements.  For  example,  the  multiprocessor  branch  at  point  C 
is  made  to  accommodate  MOS  microprocessors.  The  only  practical 
way  to  use  these  devices  in  the  DP  is  in  a  multiprocessor.  The  cor¬ 
responding  branch  at  point  B  is  made  more  because  of  the  intrinsic 
interest  of  the  multiprocessor  approach.  There  are  in  existence  high 
performance  microprocessor  designs  which  appear  suitable  for  this 
approach.  At  the  present  time  the  designs  are  custom  (not  commer¬ 
cially  available).  One  such  design  is  the  Hughes  SOS  C-MOS  processor. 
Three  of  these  in  a  multiprocessor  design  should  be  able  to  satify  the 
DP  requirements. 


The  branches  at  the  next  level,  commercial  versus  custom,  are 
required  because  commercial  sources  do  not  exist  for  some  of  the 
interesting  variations.  An  example  of  this  is  the  branch  to  custom 
at  point  4.  At  the  present  time  there  does  not  exist  a  one  or  two  chip 
microprocessor  which  can  satisfy  the  DP  requirements.  Since  it  is 
quite  likely  to  be  beyond  1980  when  such  a  design  becomes  commer¬ 
cially  available,  a  custom  design  was  chosen  for  the  study. 
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Figure  68,  Selection  of  Processor  Types  for  Cost  Tradeoffs 

The  circled  numbers  at  the  bottom  of  Figure  68  identify  the  chosen 
variations.  A  brief  description  of  each  is  given  below  and  a  more 
detailed  description  in  the  next  section. 


Configuration 


Description 


This  design  was  generated  in  the  technology 
study,  where  it  was  called  DP-X.  It  uses 
commercial,  bipolar  microprocessors. 

This  is  essentially  the  breadboard  DP-2 
packaged  with  hybrid  integrated  circuit 
modules. 

A  multiprocessor  using  3  custom  design 
microprocessor  CPUs. 


4 


A  monoprocessor  with  a  custom  design 
microprocessor  CPU. 

5  Two  distributed  processors.  This  is  very- 
similar  to  the  baseline  design  (Configura¬ 
tion  1)  and  also  uses  commercial,  bipolar 
microprocessors.  Each  processor  in  this 
variation  has  somewhat  more  than  one  half 
of  the  throughput  capability  that  variation 
one  has. 

6  Four  distributed  processors.  Each  pro¬ 
cessor  is  a  multiprocessor  with  4  MOS 
CPUs. 

9.3  CONFIGURATION  DESCRIPTIONS 
9.  3.  1  Overall  Description 

In  this  subsection  the  total  digital  processing  system  used  in  the 
cost  analysis  is  described.  While  the  major  tradeoff  areas  have  to  do 
with  processor  implementation  (and  more  specifically  with  CPU)  it  is 
necessary  to  include  the  entire  system  since  changes  in  the  processor 
may  lead  to  other  changes. 

The  DP  weapon  bus  design  allows  for  16  stations  including  the 
master  processor.  However,  it  is  not  likely  that  all  16  will  be  used 
inmost  weapon  configurations.  For  the  purposes  of  the  cost  study, 
the  weapon  bus  has  eight  stations.  One  of  these  is  used  by  the  DP 
(or  the  master  DP  for  the  distributed  processor  cases).  Each  of  the 
other  stations  has  a  bus  interface  unit  (BIU)  or  a  satellite  DP.  Where 
a  DP  occupies  the  station  (master  or  satellite)  the  BIU  function  is 
absorbed  into  the  processor.  The  satellite  processors  also  have  to 
furnish  an  interface  to  the  "distributed  element"  (subsystem)  located 
at  that  station. 

The  eight  stations  are  connected  together  by  a  bus  consisting  of 
10  twisted,  shielded  pairs.  The  connection  to  the  bus  at  each  station 
is  by  a  single  connector. 

The  digital  processing  system  does  not  contain  its  own  power 
supply.  Power  of  the  correct  wave  form  is  supplied  to  the  master  DP 
via  a  power  connector.  Power  is  distributed  to  the  BIU's  along  the 
bus.  Satellite  processors  are  supplied  by  the  weapon  system  through 
their  own  power  connectors. 

Thus,  the  system  considered  in  the  cost  study  consists  of  8  boxes 
and  the  weapon  bus.  Of  the  8  boxes,  (1+N)  are  processors  and  (7-N) 
are  BIUs  where  N  is  the  number  of  satellite  processors. 

9.  3.  2  Box  Descriptions 

The  processor  box  (whether  for  master  or  satellite  processors) 
have  three  external  connectors.  One  is  for  input  power  and  one  is  for 


the  bus  connection.  The  third  connector  is  used  to  interface  with  a 
distributed  element  or  as  a  test  connector  for  laboratory  testing. 

The  processor  contains  a  mother  board  which  supplied  all  the 
interboard  wiring.  The  mother  board  supplies  space  for  1  to  3  CPU 
boards  (depending  on  the  configuration)  1  to  3  memory  boards,  2  1/0 
boards  and  2  spares. 

The  BIU  box  has  two  connectors,  one  for  the  bus  and  one  for  the 
distributed  element.  It  contains  a  single  circuit  card  and  no  mother 
board. 

9.  3.  3  Circuit  Card  Descriptions 

In  order  to  eliminate  extraneous  variables  from  the  cost  study,  a 
standard  circuit  board  was  chpsen  for  all  configurations  and  for  all 
functions  within  a  configuration.  The  standard  chosen  was  a  3x4 -inch 
ceramic,  multilayer  board.  The  standard  packaging  technique  used 
was  to  purchase  all  integrated  circuits  or  chips,  place  them  in  lead¬ 
less  carriers  and  place  the  carriers  on  the  circuit  baords.  The  only 
variation  from  this  procedure  was  in  Configuration  2  in  which  the  chips 
are  assembled  in  hybrid  integrated  circuits  in  1  - 5/8x1  - 1 /4-inch  module 
modules.  This  latter  arrangement  was  chosen  because  Configuration  2 
corresponds  very  closely  to  an  existing  design  (packaged  in  hybrids) 
for  which  we  have  a  considerable  amount  of  information.  As  it  turned 
out,  this  exception  did  lead  to  an  anomaly  in  the  study  results  which 
will  be  discussed  later. 

Central  Processing  Unit  (CPU)  Cards 

The  CPU  design  is  the  source  of  all  the  variations  among  the  six 
configurations.  The  designs  vary  from  MSI  (Configuration  2)  through 
bipolar  microprocessors  (Configurations  I  and  5),  MOS  micropro¬ 
cessors  (Configuration  6)  to  custom  LSI  designs  (Configurations  3 
and  4).  Configuration  1,  the  base  line,  is  based  upon  the  DP-X  design 
developed  in  the  technology  task.  It  is  designed  around  the  AMD  2901 
bit  sliced,  bipolar  microprocessor.  This  design  is  highly  pipelined  in 
order  to  obtain  the  throughput  required  for  DP.  The  design  has  two 
functionally  identical  parts  each  of  which  can  fit  on  one  circuit  board. 
Each  contains  68  integrated  circuits.  These  boards  are  essentially 
arithmetic  units  (with  their  own  microprogram  control);  one  for 
address  arithmetic  and  one  for  general  arithmetic.  Additional  CPU 
functions  are  contained  on  a  third  board  with  60  integrated  circuits. 

Configuration  5  is  similar  to  Configuration  I  in  that  it  uses  bipolar 
microprocessors  in  the  CPU.  However,  since  it  is  a  distributed  con¬ 
figuration,  each  processor  does  not  require  as  high  a  throughput  as 
Configuration  1.  Hence,  the  high  degree  of  pipelining  is  not  required 
and  the  design  is  much  closer  to  the  standard  design  using  these  micro¬ 
processors.  The  design  can  be  obtained  from  Configuration  I  essenti¬ 
ally  by  eliminating  one  of  the  arithmetic  boards.  Thus,  the  configura¬ 
tion  5  has  two  processors.  Each  processor  has  a  CPU  which  requires 
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2  circuit  boards.  One  circuit  board  is  equivalent  to  one  of  the  micro¬ 
programmed  arithmetic  boards  of  Configuration  1  and  the  other  board 
contains  additional  CPU  functions  and  is  equivalent  to- the  third  CPU 
board  in  configuration  one. 

Configuration  2  is  based  upon  the  breadboard  DP-2,  The  design 
uses  MSI  integrated  circuits  place  in  hybrid  modules.  These  hybrid 
modules  are  very  similar  to  the  modules  used  in  the  Hughes  CMP 
design.  Ten  hybrid  modules,  21  PROMs  for  the  microdecode  function, 
ord  5  Ti  iBctllaneeus  h!Sl  chips  art  required  for  iht  CPU,  These  parts 
are  placed  on  three  circuit  boards. 

Configurations  3  and  4  are  similar  in  that  they  both  use  custom 
LSI  designs.  Configuration  3  is  a  multiprocessor  design.  That  is, 
it  uses  three  CPUs  but  a  single  memory.  Each  processor  in  this 
design  is  similar  to  the  Hughes  bOS  C-MOS  processor  and  has  a 
throughput  somewhat  greater  than  I  million  short  operations  per 
second.  The  technical  problem  in  this  design  (excluding  software 
considerations)  is  controlling  access  to  the  program  and  data  memo¬ 
ries  to  minimize  interference  among  the  processors.  A  preliminary 
design  for  the  memory  management  and  other  ancillary  CPU  functions 
was  partitioned  for  LSI  cell  arrays.  Seven  such  cell  arrays  plus  five 
additional  MSI  chips  are  required.  Thus,  this  CPU  requires  3  custom 
designed  LSI  chips,  7  LSI  cell  arrays  and  5  MSI  chips. 

Configuration  4  is  not  a  multiprocessor.  The  major  CPU  functions 
are  implemented  in  two  i2l  LSI  chips.  Some  ancillary  functions  are 
required  and  these  are  contained  in  two  LSI  cell  arrays  for  a  total  of 
4  chips.  Both  Configurations  3  and  4  require  only  one  circuit  board 
for  the  CPU. 

Configuration  6  was  included  in  the  cost  study  to  determine  how 
MOS  microprocessors  would  perform  in  the  DP  role.  On  the  surface, 
the  application  of  MOS  microprocessors  seems  quite  appealing  since 
they  can  include  essentially  the  entire  CPU  functions  on  a  single  chip. 
These  microprocessors  are  available  in  4-bit,  8-bit  and  16-bit 
versions.  Unlike  most  of  the  bipolar  microprocessors,  the  4-bit  and 
8-bit  devices  cannot  easily  be  combined  to  make  a  16-bLt  processor. 
Hence,  the  study  considered  only  the  16-bit  divices.  The  best  of  the 
16- bit  microprocessors  have  a  throughput  (for  short  instructions)  of 
the  order  of  250,  000  operations  per  second.  Hence,  it  would  take  a 
minimum  of  twelve  such  processors  to  satisfy  the  DP  requirements 
even  if  there  were  no  difficulty  with  their  long  instructions  such  as 
multiply  and  divide.  However,  this  minimum  number  assumes  that 
the  total  processing  load  can  be  divided  into  parcels  which  just  fit  the 
capacity  of  the  microprocessors.  In  general,  this  is  not  the  case  and 
there  is  significant  inefficiency  in  applying  multiple  processors  to  a 
set  of  defined  processing  tasks.  For  the  purposes  of  this  cost  study 
th*!  total  efficiency  was  stl  al  75  ptretnt.  That  is,  it  tdkes  16  xuLru- 
processors  to  fill  the  DP  requirements. 

The  16  microprocessors  can  be  arranged  in  a  number  of  ways. 

One  way  would  be  to  have  16  separate  processors,  each  with  its  own 
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memory  and  its  own  defined  tasks.  This  approach  was  rejected  for 
three  reasons: 

(1)  It  was  inconsistent  with  the  overall  arrangement  chosen  for 
the  study, 

(2)  The  total  processing  load  cannot  conveniently  be  broken  up 
into  16  separate  parts. 

(3)  Even  if  each  CPU  and  its  memory  could  be  combined  upon  one 
circuit  card,  the  total  number  of  circuit  cards  would  exceed  that  for 
other  (e.  g.  ,  the  selected)  arrangements. 

Somewhat  arbitrarily  it  was  elected  to  limit  the  configuration  to  four 
processors  of  identical  design.  Therefore,  each  processor  includes 
4  microprocessors  in  a  multiprocessor  design.  As  in  Configuration  3, 
additional  circuitry  is  required  for  memory  management.  The  require¬ 
ments  for  memory  management  and  other  ancillary  functions  can  be 
approximated  by  extropolating  from  the  configuration  3  design.  The 
latter  required  7  LSI  cell  arrays  and  5  MSI  chips  for  these  functions. 
Therefore,  it  is  felt  that  ten  LSI  cell  arrays  and  6  miscellaneous  chips 
will  be  adequate  for  this  and  other  ancillary  functions.  Each  CPU  thus 
has  4  microprocessors,  10  cell  arrays  and  6  MSI  chips  all  placed  on 
1  circuit  card. 

Memory  Cards 

The  DP  main  memory  is  separated  into  two  parts:  the  program 
memory  and  the  data  memory.  The  program  memory  uses  ROM  or 
PROM,  while  the  data  memory  uses  a  combination  of  read/write 
memory  (RAM)  and  ROM  or  PROM. 

Program  Memory 

The  baseline  configuration  (number  1)  uses  a  16-bit  program 
memory  word.  For  purposes  of  the  cost  study  it  was  assumed  that 
all  configurations  would  use  the  same  size  word  and  that  8000  words 
are  required.  The  DP  breadboard  (on  which  Configuration  2  was  based) 
uses  a  24-bit  program  memory  word,  however,  with  this  size  word  a 
somewhat  smaller  number  of  words  would  be  required;  therefore,  to 
to  simplify  the  study,  it  was  assumed  that  the  total  number  of  required 
bits  would  be  the  same. 

To  determine  chip  count,  a  standard  chip  of  512  words  by  8  bits 
was  assumed.  Sixteen  of  these  chips  (making  up  4K  words)  can  be 
placed  on  the  standard  circuit  card  if  they  are  packaged  in  the  leadless 
carrier.  In  addition  to  the  memory  chips,  8  MSI  chips  are  required 
for  memory  control  and  buffering.  In  the  first  four  configurations,  two 
of  these  memory  cards  (PM  cards)  are  required  to  make  up  the  total 
8K  words. 

For  the  distributed  processor  configurations  (5  and  6),  additional 
program  memory  is  required  because  of  duplication  of  functions  (e.  g,  , 
initialization  routines)  and  inefficiencies  in  distributing  the  functions 
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among  the  memory  modules.  The  actual  increase  can  only  be  deter- 
niined  Iron,  a  detailed  analysis  for  each  possible  case,  however  a 
feeling  for  the  magnitude  of  the  increase  can  be  had  from  the  following 
argument.  Statistically,  over  a  large  number  of  systems,  the  end¬ 
point  of  the  total  program  assigned  to  a  processor  will  have  a  uniform 
distribution  over  the  last  memory  module  required.  Therefore,  the 
mean  unused  memory  for  each  processor  is  one  half  of  a  memory 
^  module.  Thus,  each  additional  processor  added  to  the  system  results 

in  an  additional  one -half  of  a  memory  module  on  the  average.  This 
increase  is  in  addition  to  any  real  increase  in  requirements  due  to 
♦  duplication  of  functions.  Thus,  if  the  total  processing  load  is  split 

among  two  processors,  the  memory  needed  increases  by  something 
greater  than  one  half  of  a  memory  module,  If  the  load  is  split  among 
four  processors,  the  memory  needed  increases  by  more  than  one  and 
one  half  memory  modules.  Since  the  memory,  physically,  comes  in 
whole  modules,  the  two  cases  cited  above  require  an  additional  one 
and  two  memory  modules,  respectively. 

Based  on  the  above  argument.  Configuration  5  requires  an  addi¬ 
tional  512  words  (two  chips)  per  system  and  Configuration  6  requires 
an  additional  1024  words  (4  chips)  per  system.  In  Configuration  5, 
each  processor  will  require  one  memory  board.  The  board  will  be 
the  same  design  for  both  processors,  but  one  will  have  an  additional 
two  mrti.ory  chips  on  it.  lx.  Coiiflguiatioii  0,  tht  pru^iaxii  iiitmory 
requirement  for  each  processor  is  assumed  to  be  small  enough  that 
it  can  be  combined  on  one  board  with  the  data  memory. 

Data  Memory 


The  total  required  address  space  for  the  DP  in  one  of  the  first 
four  configurations  is  4K  words.  These  words  are  allocated  over 
scratch  pad,  constants,  flags  and  I/O  addresses.  For  the  purposes  of 
the  cost  study,  the  allocation  shown  in  Table  23  was  used.  Clearly, 
a  256x1  RAM  could  have  been  used  for  the  flags,  however,  this  would 
have  added  another  part  number  to  the  system. 

The  chips  listed  in  the  table,  along  with  8  MSI  chips,  for  memory 
control  and  buffering,  are  placed  on  one  of  the  standard  circuit  boards 
to  form  the  data  memory  (DM)  board  for  Configurations  1  through  4. 


TABLE  23.  ALLOCATION  OF  DATA  MEMORY  ADDRESS  SPACE 


NUMBER  OF  WORDS 

USE 

CHIPS 

2560 

16  -BIT  CONSTANTS 

10  512  XB  PROMS 

1024 

16-BIT  SCRATCH  PAD 

16  256  X  4  RAMS 

256 

1  -BIT  FLAGS 

1  256  X  4  RAM 

256 

I/O  ADDRESSES 

NONE  REQUIRED 
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Just  as  in  the  case  of  pro^ran.  memory,  the  dUtributed 
require  an  additional  amount  of  data  memory.  The  allocations  Con¬ 
figuration  5  is  shown  in  Table  24.  Each  processor  in  the  configuration 
requires  one  circuit  bcurd  fur  the  diita  -i  emery  K-irh  circuit  board 
requires  8  MSI  chips  for  memory  control  and  buffering. 

In  Configuration  6.  the  total  memory  requirement  for  each  pro¬ 
cessor  is  small  enough  that  the  program  memory  and  data  memory 
ca^be  combined  on  one  circuit  board.  The  memory  arrangement  for 
each  processor  is  shown  in  Table  25. 

In  the  first  five  configurations,  a  fast,  bipolar  memory  is  required. 
In  Configuration  6.  however,  it  is  possible  that  a  slower  memory  can 
be  used.^  N  MOS  memories  built  to  military  requirements  are  availa- 
bL  at  significantly  less  cost  than  pipolar  memories  N  MOS  -etnot.es 
with  300  nanosecond  access  time  have  historically 
about  80  percent  of  the  cost  of  bipolar  memories. 

with  5b0-ua«osccund  access  tm  ^  have  been  procured  at  about  40  per¬ 
cent  of  bipolar  memory  costs.  In  this  cost  study,  it  v/as  assumed 
that  the  300-nanosecond  access  time  would  be  required  to  satisfy  the 
needs  of  the  multiprocessor  configuration. 

Input/Output  (I/O)  Circuit  Cards 

In  the  breadboard  DP-2  system,  the  BIU  function  is  to 

the  DP.  Internal  to  the  DP  are  I/O  circuits  to  interface  with  the  BIU, 
and  circuits  to  perform  the  bus  master  control  function.  Considerable 
circuitry  can  be  saved  by  combining  these  functions.  This  approach 
was  taken  for  the  cost  study. 


Single  Processor  Configurations 


In  the  Configurations  1,  2,  3  and  4,  the  processor  I/O  circuits 
perform  four  functions; 

•  Processor  Master  clock 

•  Interface  with  BIU 

•  BIU  function 

•  Bus  master  control  function. 

A  preliminary  design  combining  these  four  functions  was  made 
using  a  microprocessor.  The  microprocessor  chosen  was  the  SMS 

300.^  The  use  of  the  microprocessor  it 

of  random  logic  circuitry  in  the  present  design  but  not  all  of  it.  There 
were  three  approaches  for  implementing  the  remaining  random  logi  . 


Available  MSI 
Custom  LSI 
Semi-custom  LSI. 
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TABLE  24.  DATA  MEMORY  ALLOCATION  FOR  CONFIGURATION  5 


PROCESSOR  NUMBER  1 


NUMBER  OF 

WORDS 

CONSTANTS 

2000 

SCRATCH  PAD 

750 

FLAGS 

256 

NUMBER  OF 
CHIPS 


PROCESSOR  NUMBER  2 


NUMBER  OF 
WORDS 


NUMBER  OF 
CHIPS 


TABLE  2  5.  MEMORY  ARRANGEMENT  FOR  CONFIGURATION  6 


MEMORY  TYPE 


CONSTANTS 


SCRATCH  PAD 


4K  WORDS 
16  CHIPS 


1  5K  WORDS 
6  CHIPS 


0.5K  WORDS 
8  CHIPS 


256  WORDS 
1  CHIP 


2K  WORDS 
8  CHIPS 


1.5K  WORDS 
6  CHIPS 


0.5K  WORDS  0,5K  WORDS 


0.5K  WORDS  0,25K  WORDS 

B  CHIPS  4  CHIPS 


1.5K  WORDS 
6  CHIPS 


0.5K  WORDS 
2  CHIPS 


0  25l<  WORDS 
4  CHIPS 


9K  WORDS 
36  CHIPS 


3. OK  WORDS 
12  CHIPS 


1.5K  WORDS 
24  CHIPS 


25  CHIPS  124  CHIPS 


The  last  technique  was  chosen  for  the  cost  study.  In  particular,  an 
LSI  cell  array  approach,  proposed  by  Hughes  Newport  Beach,  was 
used.  This  approach  combines  six  to  eight  MSI  cells  in  a  single  LSI 
chip.  Development  time  for  an  LSI  array  is  about  12  weeks  and  studies 
have  shown  that  savings  relative  to  separate  MSI  chips  are  significant. 
The  technology  chosen  was  low  power  Schottky.  The  remaining  random 
logic  was  partitioned  into  8  LSI  cell  arrays.  The  total  parts  count  for 
the  I/O  circuitry  is  given  in  Table  26.  Two  circuit  boards  will  accom¬ 
modate  these  parts. 

Distributed  Processor  Configurations 

In  these  configurations,  the  master  DP  must  perform  the  same  I/O 
functions  the  single  DP  does  in  the  preceding  configurations.  Therefore 
it  requires  the  same  I/O  circuitry.  The  satellite  DPs  could  be  con¬ 
nected  into  the  system  by  means  of  an  external  BIU,  or  the  BIU  could 
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TABLE  26.  PARTS  LIST  FOR  PROCESSOR  INPUT/OUTPUT 


be  absorbed  into  the  satellite  DP  I/O.  The  overall  system  cost  is 
probably  less  for  the  latter  arrangement.  The  functions  to  be  per¬ 
formed  by  the  satellite  processor  I/O  are: 


•  Processor  master  clock 

•  Interface  with  BIU 

•  BIU  function 

•  Interface  with  one  or  more  weapon  subsystems. 

A  detailed  analysis  of  the  circuitry  differences  between  the  master  and 
satellite  I/O's  was  not  done.  Instead,  the  assumption  was  made  that 
the  two  sets  of  functions  would  require  equivalent  amounts  of  circuitry. 
Since  the  functions  are  not  identical,  however,  at  least  one  of  the  cir¬ 
cuit  boards  in  the  satellite  DP  I/O  will  differ  from  the  corresponding 
board  in  the  master  DP  I/O.  Thus,  in  the  complete  system,  there  are 
three  I/O  circuit  board  designs.  The  master  DP  uses  one  each  of 
designs  one  and  two,  and  each  satellite  DP  uses  one  each  of  designs 
one  and  three.  The  cost  of  designs  two  and  three  is  assumed  to  be  the 
same. 

Bus  Interface  Unit  (BIU)  Card 

The  LSI  cell  array  approach  was  also  used  for  the  BIU  design 
treated  in  the  cost  study.  The  circuitry  for  the  data  slave  function, 
the  interrupt  function  and  the  bus  race  function  was  partitioned  into 
nine  cell  arrays.  In  addition,  three  small  PROMs  are  required. 

This  circuitry  fits  on  one  standard  circuit  card  in  the  BIU  box. 

9.  4  Production  Costs 

The  estimated  production  costs  for  the  six  different  configurations 
were  developed  using  a  computer-based  cost  model.  The  cost  model 
is  based  on  experience  from  numerous  programs  which  have  had 
equipment  produced  in  Hughes  Tucson  factory,  and  has  demonstrated 
good  accuracy  in  predicting  production  costs.  Outputs  from  any  cost 
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model  are  only  as  good  as  the  inputs.  The  major  inputs  to  the  cost 
model  are  the  prime  material  costs  and  the  labor  costs.  This  section 
describes  the  cost  model  and  the  basis  for  material  and  labor  cost 
estimates. 

9.4.1  Cost  Model 

The  cost  model  summarizes  costs  at  various  levels.  The  three 
top  levels  are  selling  price,  manufacturing  cost  and  factory  cost.  The 
relations  between  these  costs  are  defined  by  the  following  equations; 

Price  ^  (1  +Q')(1  +p) 

The  following  definitions  apply: 

Price  -  The  cost  to  the  customer. 

Cj^  -  Cost  at  manufacturing  level  or  manufacturing  cost. 

O'  -  General  and  administrative  cost  factor  (G&A). 
p  -  Profit  factor. 

Cp  -  Factory  cost. 

Sp  -  Factory  support  factor.  This  factor  takes  into  account 
the  effort  required  to  maintain  the  production  capability 
and  solve  manufacturing  problems.  The  factor  is 
expressed  as  a  percentage  of  the  factory  cost.  In  general, 
it  will  vary  with  the  type  of  program.  Introduction  of  new 
manufacturing  methods  would  increase  this  factor,  for 
example. 

Sp  -  Engineering  support  factor.  This  factor  takes  into  account 
the  support  given  by  the  engineering  staff  to  the  manu¬ 
facturing  process.  It  involves  such  things  as  design 
changes  to  accommodate  production  practices  and  ensur¬ 
ing  that  produced  equipment  satisfies  the  specifications. 

In  the  cost  study  reported  here,  the  summary  level  used  for  com¬ 
parison  is  the  factory  cost,  Cp.  The  other  factors  used  to  obtain  the 
higher  summary  levels  are  insensitive  to  the  differences  in  the  con¬ 
figuration  and  hence  only  tend  to  obscure  the  differences, 

9.4.2  Development  of  Factory  Cost 


Factory  cost  is  the  summation  of  two  quantities:  labor  cost  and 
material  cost.  Both  of  these  latter  costs  involve  a  complex  of  input 
data. 


The  material  costs  start  with  the  cost  for  supplying  the  basic  or 
"prime"  material.  This  is  the  cost  of  buying  just  enough  material  for 
supplying  the  needs  of  the  system  to  be  built.  The  prime  material  cost 
is  adjusted  by  three  factors;  freight  allowance,  material  attrition  and 
material  expense. 


:  -  a'.  “ 
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Fre\g^?t'':/i’l^vvance,c4j)iers  the  expense  of  shipping  the  material  and 
IS  expressedias  a  pe'rijentage  of  material  costs.  Obviously  a  sstraight 
pe'rcentag^  of  Imgi'terial  costs  is  inaccurate  for  this  factor,  but  since  the 
percentagt'e' is  small,  it  does  not  lead  to  significant  inaccuracies  in  the 
'  final  result. >  '  /  , 

■'  j*  ' 

Material  atti-i,tion  allows  for  the  fact  that  some  of  the  material  will 
fail  and  have  to  be^, scrapped  and  that  the  project  will  end  with  some 
surplus  of  material  that, has  to  be  disposed  of.  ,  The  surplus  may  come 
about  because  rff  spec  changes  which  require  a  new  part.  This  factor 
is  derived'from  historic%14ata. 

Material  eXj.;eiise  cuvets  the  Indirect  effort  required  to  order  and 
stock  the  material.  The  factor  is  derived  from  historical  data. 

The  equation  which  describes  how  the  above  three  factors  operate 

T  'v 


.  ^MT  "  ^PM  ^  ^  ^M^* 


The  pertinent  definitions  aret 

'  k 

CmT  =.  Material  co^t 
CpM  =  Cost  for  the'prime  material 
Ap  =  Freight  allowance 
A^  =  Allowance  for  attrition 
=  Material  expense 

With  respect  to  the  present  cost  study,  the  only  variable  is  the 
cost  for  prime  material.  These  costs  will  be  discussed  in  a  following 
section. 

Labor  costs  are  developed  from  four  factors;  standard  hours, 
labor  index,  labor  rate  and  labor  expense.  The  formula  connecting 
these  quantities  is 

=  (Hg,j,j^)(index)(rate)(Ej^). 

In  the  above  equation,  the  following  definitions  apply. 

Cl  -  Labor  cost 
Hstd  "  Standard  hours 

Index  -  Labor  index  which  adjusts  standard  hours  to  actual  hours 

Rate  -  Hourly  (or  monthly)  rate  for  the  particular  labor  involved 
(fab,  assembly  or  test). 

Et  -  Labor  expense  or  overhead. 
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Thtre  are  four  types  of  labor  for  which  standard  hours  are 
estimated.  These  are  fabrication,  assembly,  inspection,  and  test. 
These  estimates  are  computed  on  the  basis  of  time  it  would  take  a 
traintrd  wurlftir  lo  accoinpliah  thi^  task  if  there  were  no  set-up  time, 
rework,  ob  stops  for  inspection.  For  well  established  procedures,  the 
standard  hours  are  estimated  on  the  basis  of  experience.  For  new 
procedures,  a  time  and  motion  study  is  done. 

The  labor  index  adjusts  standard  hours  to  actual  hours.  It  takes 
into  account  the  effort  required  for  set-up  for  the  task,  rework 
required  and  inefficiencies  due  to  such  things  as  waiting  for  an  inspec¬ 
tor  to  approve  the  work. 

There  are  separate  labor  rates  for  each  category  of  labor.  These 
rates  are  establi'shed  on  the  basis  of  negotiation  or  history  from 
similar  on-going  projects.  Labor  expense  is  a  negotiated  quantity, 
r  or  the  presefil  study,  labor  rates  atid  expense  were  used, 

9.4.3  Prime  Material  Costs 

Material  costs  were  gathered  on  the  basis  of  requirements  for 
1000  systems.  Extrapolations  of  costs  for  a  lai*ger  number  of  systems 
is  done  in  the  computer  cost  model.  Most  of  the  costs  were  based  on 
vendor  planning  purpose  quotes.  Where  the  quote  did  not  cover  the 
necessary  quantity  or  time  period,  extrapolations  were  made.  The 
assumption  was  made  that  material  would  be  purchased  in  1980. 
Extrapolations  to  that  time  period  included  effects  of  technological 
advance  and  competition  but  did  not  include  inflation.  Prices  are  in 
1976  dollars. 

Costs  for  Integrated  Circuits 

The  costs  of  ICs  used  in  the  cost  analysis  are  shown  in  Table  27. 
The  origins  of  the  costs  are  discussed  below. 

Memory 

The  costs  of  semi-conductor  memories  have  declined  rapidly  over 
the  last  several  years.  Figure  69  illustrates  the  trend  for  military 
quality  memories.  By  1980,  RAM  should  be  available  for  about  1,  5<f 
per  bit  and  PROM  for  a  few  tenths  of  a  cent  per  bit.  The  chart  indi¬ 
cates  that  the  price  reduction  is  accompanied  by  (and  to  a  large  part 
a  result  of)  a  corresponding  increase  in  density  (bits/chip).  For  the 
purposes  of  the  study,  the  price  was  extrapolated  to  1980  but  chip 
densities  corresponding  to  1976  were  used.  This  inconsistency  might 
affect  the  study  results  in  two  ways.  First,  the  higher  density  chips 
expected  in  the  future  will  allow  packaging  on  less  board  space,  lead¬ 
ing  to  a  cost  reduction,  particularly  in  Configurations  1  through  5. 
Second,  the  memory  module  size  will  probably  go  up.  For  example, 
module  size  for  program  memory  might  be  most  economical  at  IK  or 
2K  words  rather  than  500  words.  Tnis  effect  would  affect  primarily 
Configurations  5  and  6  (the  distributed  processor  cases).  Total 
memory  usage  will  increase  in  those  cases. 
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TABLE  27.  ESTIMATED  COSTS  FOR  INTEGRATED  CIRCUITS  IN  1980 


COST (DOLLARS) 

TYPE 

1  TO  4 

CONFIGURATION 

5 

6 

512  X  8  ROM 

8  75 

8.75 

7.00 

SMALL  ROM 

3.00 

3.00 

3,00 

IK  RAM 

15.62 

15.62 

12  50 

FIFO 

6  20 

5.00 

3  00 

SOS  C  MOS  CPU  CHIP 

50,00 

N/A 

N/A 

I^L  CPU  CHIP 

50  00 

N/A 

N/A 

MOS  CPU 

N/A 

N/A 

25  00 

AMD  2901 

22.85 

22.85 

N/A 

AMO  2914 

10.00 

9.00 

N/A 

SMS  300 

40  00 

37.50 

35.00 

IV  BYTE 

7.00 

6.50 

6.00 

CELL  ARRAYS 

5.30 

5  30 

4  93 

HYBRIDS 

125  00 

N/A 

N/A 

OTHER  MISCELLANEOUS  MSI 
CHIPS 

1,0(J' 

1.00 

1.00 

QUARTZ  CRYSTAL 

10.00 

9.00 

8.00 

Configuration  6  uses  N  MOS  memories  which  is  cheaper  than 
bipolar  memories.  Experience  has  been  that  military  grade  N  MOS 
memories  with  300  nanosecond  access  time  can  be  procured  at  about 
80  percent  of  the  corresponding  bipolar  types.  The  500- nanosecond 
memories  are  less,  about  40  percent  of  the  bipolar.  Since  the  memory 
access  time  requirements  of  the  4-processor  multiprocessor  has  not 
been  analyzed  in  detail,  the  conservative  approach  of  specifying  300 
nanosecond  memory  has  been  taken. 

The  estimated  costs  for  the  FIFOs  (first  in-first  out)  memories  is 
based  on  a  vendor  quote. 


Custom  LSI  Designs 

A  cost  projection,  based  on  past  experience,  was  made  to  give  a 
basis  for  the  cost  estimates  for  the  custom  design  CPUs  in  Configura¬ 
tions  3  and  4.  The  ground  rules  for  the  projection  were: 

•  Functional  complexity  and  speed  requirements  in  the  GMP 
ge 


•  Full  burn-in  and  screening  required 

•  Prototype  design  in  1978  with  production  units  procured  in 

1980 

•  Costs  for  1000  units 

•  Chip  size  will  be  limited  to  about  0.  2x0.  2-inch. 

SOS  C-MOS  and  I^L  were  considered  to  be  the  most  promising 
candidate  technologies.  The  results  of  the  projection  are  shown  in 
Table  28.  The  use  of  CMOS  on  sapphire  requires  only  moderate 
extension  of  current  technology  .  Achievement  of  the  required  func¬ 
tional  complexity  may  cause  the  chip  size  to  exceed  0.  2x0.  2-inch  or 
may  require  a  CI'U  set  comprised  of  two  chips  as  shown  in  the  table. 
The  use  of  IIL  technology  is  based  upon  projections  that  new  improve¬ 
ments  in  this  technology  will  emerge  more  rapidly  than  for  the  other 
candidate  technologies.  Higher  speed  nonsaturating  configurations  of 
IIL  devices  have  already  been  developed.  Higher  packaging  densities 
of  IIL  and  inherent  flexibilities  make  it  probable  that  the  CPU  can  be 
irnpli-fni.  fill’d  in  litn.-  chlp^  Th*  cumpic^ily  and  apeii-d  ents  of 

the  custom  chips  are  great  enough  to  push  the  state  of  the  art.  Hence 
chip  yield  will  be  low  as  shown  in  the  table. 

Considering  the  results  of  the  above  cost  projection,  a  more  con¬ 
servative  approach  was  taken  for  the  cost  analysis.  In  the  SOS  C-MOS 
case,  it  was  decided  to  use  a  chip  of  somewhat  less  complexity  in  a 
multi-processor  configuration.  The  model  is  the  Hughes  SOS  C-MOS 
single-chip  processor.  Three  of  these  are  required  for  the  multi¬ 
processor  of  Configuration  3.  Because  the  complexity  is  less,  the 
yield  will  be  higher  and  cost  lower  (per  chip)  than  shown  in  Table  27. 

For  the  I  L  case,  the  more  conservative  approach  of  using  a  two 
chip  design  was  chosen.  Again  the  complexity  of  each  chip  is  less, 
yield  is  higher  and  cost  is  down  from  the  results  shown  in  Table  27. 

TABLE  28.  PROJECTED  COSTS  FOR  LSI  MONOPROCESSOR  CPU 


WAFER  PROCESSING  COST 


DEVICE  YIELD  PER  WAFER 


PROCESSING  COST  PER  DEVICE 


ASSEMBLY,  TEST,  PACKAGING 


PACKAGE  YIELD 


MANUFACTURING  MARGIN 


SELLING  PRICE  PER  CHIP 


NUMBER  OF  CHIPS  REQUIRED  PER  SET 


SELLING  PRICE  PER  SET 


SOS  CMOS 

|2l 

$  65.00 

$  65.00 

4 

3 

16  25 

21.66 

8.00 

9.00 

75  percent 

75  percent 

65  percent 

65  percent 

54.00 

87.50 

2 

1 

$  108.00 

$  87.50 
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It  was  estimated  that  each  chip  would  cost  about  $50,  yielding  a  total 
cost  higher  than  shown  in  the  table. 

uther  LSI 

Most  of  the  other  LSI  prices  were  based  on  vendor  quotes.  In 
some  cases  the  vendor  extrapolated  the  quotes  to  1980.  In  the  other 
cases  it  was  assumed  that  prices  would  drop  10  to  15  percent  per  year, 
a  decline  which  has  been  typical  for  such  parts.  The  prices  given  for 
the  MOS  CPU  and  the  2914  are  estimates  made  without  benefit  of  a 
vendor  quote.  The  system  costs  for  integrated  circuits  for  each  con¬ 
figuration  are  given  in  labies  2v  through  35. 

Other  Material  Costs 

The  costs  for  the  other  material  used  in  the  system  is  summarized 
in  Table  35  with  an  indication  as  to  the  source  of  the  data.  Costs  for 
connectors  were  estimated  as  were  costs  for  mother  board  material 
and  miscellaneous  hardware.  The  miscellaneous  electronics  includes 
resistors  and  capacitors  for  bypassing.  These  were  counted  at  one 
resistor  or  capacitor  for  every  four  integrated  circuits.  Table  36  also 
suniriiarises  the  if'tal  fi.aterial  fcsT  for  tytUm. 

9.4.4  Labor  Costs 

There  is  only  one  aspect  in  which  the  labor  costs  for  the  six  con¬ 
figurations  might  differ  from  historical  costs.  This  is  in  the  process 
of  putting  the  integrated  circuit  chips  into  the  leadless  carriers.  This 
is  a  new  process  for  the  Tucson  factory  and  required  a  time  and  motion 
study  to  estimate  the  labor.  All  of  the  configurations  used  this  process 
in  all  or  part  of  the  equipment.  Ihe  only  configuration  that  did  not  use 
it  for  everything  was  2,  which  had  the  CPU  in  hybrid  integrated  circuit 
modules.  Since  the  costs  for  the  hybrid  modules  were  based  on  the 
estimates  of  a  different  Hughes  factory  (which  has  experience  in  pro¬ 
ducing  the  modules)  and  the  cost  of  the  use  of  the  leadless  carriers 
was  based  on  a  study,  it  may  be  expected  that  Configuration  2  will  be 
atypical  relative  to  the  other  configurations.  The  labor  costs  for  using 
the  leadless  carriers  were  estimated  on  a  conservative  basis  since  it 
is  a  new  process.  It  is  felt  therefore,  that  all  the  other  configurations 
are  priced  high  relative  to  Configuration  2. 

9.4.5  Production  Cost  Comparisons 

The  production  cost  estimates  (at  factory  cost  level)  are  shown  in 
Table  35.  The  table  shows  the  cumulative  average  cost  per  unit  for 
producing  5000  units.  While  the  total  variation  from  the  mean  is  only 
about  ±20  percent,  it  is  felt  that  this  difierence  is  large  enough  to  show 
trends  and  give  significant  information  about  the  major  tradeoffs. 

Bipolar,  LSI  Microprocessors  Versus  MSI 

This  tradeoff  is  illustrated  by  Configurations  1  and  2.  The  former 
uses  microprocessors.  As  seen  from  the  table,  there  is  not  any  signi¬ 
ficant  differences  in  the  cost.  Configuration  1  would  have  had  fewer 
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TABLE  31.  NUMBER  OF  CHIPS  OF  EACH  TYPE  USED  IN  CONFIGURATION  3 


TABLE  33.  NUMBER  OF  CHIPS  OF  EACH  TYPE  USED  IN  CONFIGURATION  5 


TABLE  34.  NUMBER  OF  CHIPS  OF  EACH  TYPE  USED  IN  CONFIGURATION 


TABLE  35.  TOTAL  MATERIAL  COSTS 


CONFIGURATION 

SOURCE  OF 

COST  DATA 

ITEM 

1 

2 

3 

4 

5 

6 

INTEGRATED 

CIRCUITS  AMD 
hybrid  INTE¬ 
GRATED  CIRCUIT 

MODULES 

1,809 

2,654 

1,52B 

- ■ - 1 

1,447 

2,166 

2,398 

SEE  TABLES  26  AND 

28  THROUGH  33. 

CHIP  CARRIERS 

402 

2.32 

221 

210 

506 

408 

VENDOR  QUOTE 

CIRCUIT  BOARDS 

639 

649 

549 

549 

778 

826 

VENDOR  QUOTE 

CIRCUIT  BOARD 
CONNECTORS 

300 

300 

260 

260 

360 

400 

ESTIMATE 

MOTHER  BOARD 
CONNECTORS 

20 

20 

20 

20 

40 

80 

ESTIMATE 

BOX  CONNECTORS 

340 

340 

340 

340 

360 

400 

ESTIMATE 

HARNESS 

992 

992 

992 

992 

992 

992 

VENDOR  QUOTE 

MOTHER  BOARD 
MATERIAL 

102 

102 

62 

82 

124 

16B 

ESTIMATE 

MISCELLANEOUS 
ELECTRONICS; 
RESISTORS,  ETC. 

100 

60 

55 

52 

127 

103 

ESTIMATE 

SHEET  METAL, 
SCREWS,  MISCEL 
LANEOUS  MATERIAL 

75 

75 

75 

75 

75 

75 

ESTIMATE 

TOTAL 

4,779 

5,424 

4,122 

4,027 

5,52B 

5,B50 

TABLE  36.  CUMULATIVE  AVERAGE  COST  PER  UNIT  FOR  5000  UNITS 


CONFIGURATION 

1 

2 

3 

4 

5 

6 

MATERIAL  COST  PER  UNIT- 
DO  L  LARS 

5,035 

5,714 

4,342 

4,242 

5,B24 

6,163 

LABOR  COST  PER  UNIT- 

DOLLARS 

2,279 

1,524 

1,435 

1,3SS 

2,665 

2,546 

FACTORY  COST  PER  UNIT 

DOLLARS 

7,314 

7,23B 

5,777 

5,630 

8,689 

B,709 

DEVIATION  FROM  MEAN 

PERCENT 

1.2 

0.1 

-20 

-22 

20 

20 
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parts,  and  therefore  lower  cost,  if  a  suitable  LSI  microprogram  control 
chip  had  been  available  for  the  design.  Furthermore,  as  discussed 
previously,  Configuration  2  is  probably  priced  low  in  comparison  with 
the  other  designs.  If  the  use  of  an  LSI  MCU  chip  could  have  eliminated 
40  MSI  chips,  the  burdened  material  costs  for  configuration  1  would 
drop  by  perhaps  $300.  If  the  labor  for  Configuration  2  were  raised  to 
equal  labor  for  Configuration  1,  its  cost  would  increase  about  700 
dollars.  For  these  two  adjustments,  the  cost  of  Configuration  1  rela¬ 
tive  to  Configuration  2  would  drop  $1000.  The  new  costs  would  then  be 
approximately  $7900  and  $7900.  This  is  a  great  enough  difference  to 
sIkjw  a  favorable  tr  .iid  for  th-  use  of  bipolar  upr  jcessors ,  rela¬ 

tive  to  MSI. 


Commercial  Microprocessor  Versus  Custom  LSI 


Configuration  1,  5,  and  b  use  microprocessors  in  the  CI'lI.  Con¬ 
figuration  3  and  4  use  custom  LSI.  However,  of  these,  only  1  and  4 
compare  monoprocessors.  Configuration  1,  even  if  we  deduct  the  $300 
for  using  an  LSI  MCU,  is  still  about  $1400  greater  than  4.  This  would 
appear  to  be  a  clear  trend  in  favor  of  custom  Lbl, 

Central  Processor  Versus  Distributed  Processors 

The  first  four  configurations  are  central  and  the  last  two  are  dis¬ 
tributed  designs.  The  trend  in  favor  of  the  central  designs  is  clear. 

A  particularly  good  comparison  is  between  1  and  5,  since  they  both  use 
the  same  technology.  Configuration  5  is  a  significant  $1300  greater 
than  1. 

This  is  not  an  unexpected  result.  It  has  historically  been  observed 
that  computing  power  of  a  system  is  proportional  to  the  square  of  the 
cost  (as  long  as  one  stays  within  the  same  technology).  Thus,  increas¬ 
ing  the  cost  of  a  computing  system  by  40  percent  should  allow  doubling 
of  the  computing  power.  This  assumes  a  single  processor,  of  course. 
Doubling  the  number  of  processors  will  double  the  computing  power 
also,  but  at  twice  the  cost.  Thus,  from  the  viewpoint  of  cost,  one 
should  have  better  results  by  designing  a  central  processor  system  as 
long  as  the  capability  of  the  technology  is  not  exceeded. 

Monoprocessor  Versus  Multiprocessor 

Configurations  3  and  4  are  a  multiprocessor  and  monoprocessor, 
respectively.  The  cost  difference  does  not  seem  to  be  significant. 

Use  of  Microprocessors 

Commercial  microprocessors  are  used  in  the  CPUs  of  Configura¬ 
tions  1,  5,  and  6.  As  discussed  before,  the  bipolar  microprocessor 
sets  seem  to  compare  favorably  with  MSI  implementations  (assuming 
that  a  suitable  MCU  chip  becomes  available).  It  compares  unfavorably 
with  a  custom  LSI  design.  It  is  clear  that  present  day  MOS  micro¬ 
processors  (Configuration  6)  will  not  lead  to  an  inexpensive  system. 
These  processors  would  have  to  have  a  very  large  increase  in  their 
processing  capability  (a  factor  of  3  or  4)  before  they  could  approach 
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the  cost/performance  figure  for  a  custom  LSI  approach.  In  fact,  close 
scrutiny  of  the  material  costs  used  in  this  study  indicates  that  a  lower 
bound  on  the  cosle  for  a  commercial  microprocessor  system  is  given 
by  Configurations  3  and  4.  The  latter  two  designs  are  microprocessor 
designs  also,  of  course.  The  difference  is  that  these  are  custom 
drilgntd  nilf  rcf  rof  'cleBTgr^^J  tu  accoinpliaki  i-uid  of  join. 

The  MOS  processors  are  not. 

9.  5  DEVELOPMENT  COSTS 

This  section  derives  estimates  for  the  development  costs  of  the 
six  different  configurations  and  makes  some  qualitative  judgements 
relative  to  development  risk.  Only  the  hardware  development  costs 
are  considered  here.  However,  some  general  observations  about  soft¬ 
ware  development  are  made. 

The  costs  are  given  for  a  30-month  engineering  development  phase 
in  which  one  breadboard,  two  development  and  20  prototype  units  are 
built  and  tested. 

9.  5.  1  Development  Cost  Model 

The  computer-based  cost  model  used  for  development  costs  was 
derived  from  an  analysis  of  historical  data.  It  has  proved  quite 
accurate  in  predicting  development  costs. 

The  cost  factors  considered  in  the  cost  model  are  shown  in 
Table  37,  along  with  the  total  program  summary  for  Configuration  1. 
Special  ground  rules  for  input  to  the  cost  model  are  listed  below. 

(1)  The  program  is  assumed  to  be  conducted  and  organized  in  a 
manner  similar  to  the  AIM-VAL  engineering  development  program. 

This  similarity  pertains  particularly  to  the  interface  between  the  sys¬ 
tems  engineering  and  hardware  areas. 

(2)  Costs  for  program  management,  systems  engineering,  and 
systems  test  and  data  are  based  on  similarity  to  the  AIM-VAL  pro¬ 
gram.  Cost  variation  for  these  items  from  configuration  to  configura¬ 
tion  is  less  than  the  tolerance  on  the  numbers  for  any  given  configura¬ 
tion.  Hence,  these  costs  are  taken  to  be  the  same  for  all  configurations 

(3)  Peculiar  support  equipment  and  training  costs  were  not 
estimated. 

(4)  No  costs  are  included  for  a  preproduction  program. 

The  hardware  development  costs  for  the  six  configurations  are 
given  in  Table  38.  The  backup  data  for  the  results  shown  in  Table  37 
are  given  in  Tables  39  and  40.  With  the  exception  of  Configuration  5, 
the  development  costs  are  closely  grouped  (about  ±7  percent  if  Con¬ 
figuration  5  is  not  included).  The  variation  with  respect  to  the  total 
program  costs  are  even  smaller.  (Costs  for  program  management, 
systems  engineering,  and  system  test  and  data  must  be  added  to  the 
numbers  given  in  Table  37  to  obtain  total  program  costs.  )  It  is 
doubtful  if  such  variations  are  significant.  The  rather  high  cost  for 


TABLE  37.  PROGRAM  COST  SUMMARY  FOR  CONFIGURATION  1 


SOURCE  OF  DATA  NOTED  ON  CO  V  ER  LETTE  R  ;  DATE  20  MAY  1976 
(COSTS  IN  1975  K$  AT  MCL) 


PROGRAM  MANAGEMENT 


SYSTEMS  ENGINEERING 
AND  ANALYSIS 


SYSTEMS  TEST  AND 
EVALUATION 


HARDWARE  DEVELOPMENT 
COMMAND  AND  LAUNCH 

equipment 

O  AND  M  support  EQUIPMENT 

TRAINING 

DATA 

FACILITIES  AND  EQUIPMENT 
OTHER 


LABOR 

HOURS  percent 


872 

12  a 

714 

10.5 

907 

[ 

13.3 

TABLE  38.  HARDWARE  DEVELOPMENT  COST  SUMMARY 

(IN  $1000) 


CONFIGURATION 


3 


DEVELOPMENT  LABOR 

2955.4 

3135  7 

2445  2 

240B.3 

352B.B 

2B2B.4 

Manufacturing  labor 

673  7 

711.4 

519.2 

511.3 

B24.3 

701.5 

TOTAL  LABOR 

3629.1 

3B47.1 

2964  4 

! 

2919.6 

4353.1 

3529.9 

ODC 

647.3 

.  690.6 

739.3 

B02.5 

746.9 

7B2.7 

COST  PER  UNIT  ] 

97.7 

103.2 

81  3 

79.7 

121.6 

100.0 

TOTAL  NON  RECURRING 

2321  6 

2474.3 

207S.6 

2127  6 

2667.3 

2313  0 

TOTAL  RECURRING 

1954.B 

2063.4 

1625.1 

1594.4 

2432.7 

1999.6 

TOTAL  HARDWARE 

DEVELOPMENT  COST 

4276.5 

4537.7 

3703.7 

3  722.1 

5100.0 

4312.6 

VARIATION  FROM  MEAN 
(percent) 

0.02 

6 

-13 

-13 

19 

O.B 

TABLE  39.  INPUT  DATA  FOR  ESTIMATING  HARDWARE  DEVELOPMENT 
COSTS  FOR  CONFIGURATIONS  1,  2  AND  3 


CONFIGURATION 

1 

2 

3 

(DATE  19  MAY  1976) 

EXPECTED 

COMMENTS/RISK 

EXPECTED 

COMMENTS/RISK 

EXPECTED 

COMMENTS/RISK 

SPECIFICATIOMS 

61 

2  UNIT. 

HARNESS.  2  BIU 

8  CARDS  X  2 

16  +  40  IC'S 

63 

2  UNIT,  1 
HARNESS,  2  BIU 

9  CARDS  X  2  18 

+  40  IC'S 

49 

2  UNIT,  1 
HARNESS,  2  BIU 
2X7  CARDS 

14,  30  IC'S 

ANALOG  STAGES 

0 

0 

0 

DIGITAL  COMPONENTS 

239 

12  +  227 

137 

125  +  12 

126 

114  +  12 

BREADBOARD 

ASSEMBLIES 

B 

403  X  2/100 

9.1 

(233  +  220)  X 

2/100 

4.4 

222  X  2/100 

EXPERIMENTAL  DRAWINGS 

94 

102 

84 

PRODUCTION  DRAWINGS 

94 

102 

84 

PARTS  TO  BE  QUALIFIED 

40 

40 

30 

NEW  MATERIAL  AND 
PROCESSES 

2 

2 

2 

DEVELOPMENT  TESTS 

672 

696 

592 

ACCEPTANCE  TESTS 

1620 

1620 

1380 

BAYS  OF  STE 

4 

4 

4 

DEVELOPMENT 

ASSEMBLIES 

34 

28 

26.2 

PROTOTYPE  assemblies 

340 

280 

262 

SUBCONTRACT  SUPPORT,  mm 

21 

22 

23 

TOTAL  COMPONENTS 

500 

566 

(233  +  220)  (1.25) 

27B 

222  X  1.25 

COMP.  IN  ANALOG  MODULES 

0 

0 

0 

ANALOG  MODULES/UNIT 

0 

0 

0 

COMP.  IN  DIGITAL  MODULES 

0 

275 

220  X  1  25 

0 

DIGITAL  MODULES/UNIT 

0 

in 

0 

TYPES  OF  HYBRID  MODULES 

0 

7 

0 

SETS  OF  HYBRID  MODULES 

0 

25 

0 

BREADBOARD  UNITS 

1 

1 

1 

DEVELOPMENT  UNITS 

2 

2 

2 

PROTOTYPE  UNITS 

20 

20 

20 

subcontract  develop 

MENT,  ODC,  K$ 

290 

300 

420 

PURCHASED  PARTS  ODC,  K$ 

250 

248 

224 

HOURLY  RATE,  $ 

10.80 

10  80 

10.80 

MONTHS  TO  DEV.  PEAK 

15 

15 

15 

MONTHS  TO  ODC  PEAK 

12 

12 

12 

MONTHS  TO  END  OF 

PROGRAM 

30 

30 

30 

BURDEN,  PERCENT 

138 

138 

138 

MISC.  ODC,  PERCENT 

2 

2 

2 

DRAWING  FACTOR 

144 

144 

144 

SUBSYSTEM  DESIGN 

20 

20 

20 

154 
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TABLE  40.  INPUT  DATA  FOR  ESTIMATING  HARDWARE  DEVELOPMENT 
COSTS  FOR  CONFIGURATIONS  4,  5  AND  6 


CONFIGURATION 

4 

5  1 

(DATE  19  may  1976) 

EXPECTED 

30MMENTS/RISK  E 

XPECTED 

COMMENTS/RISK 

EXPECTED 

2  UNIT  1  1 

2  DP  +  2  MP  +  1 

HARNESS  H  2  8IU 

HARNESS  +2  8IU 

7  CARDS  X  2  - 

+  9  CARDS  X  2  - 

SPECIFICATIONS 

4S 

14  f  29  IC'S 

65 

IB  +  40  IC’S 

ANALOG  STAGES 

0 

0 

0 

DIGITAL  COMPONENTS 

115 

12  4  103 

255 

190 

BREADBOARD 

4.2 

211  X  2/100 

10.2 

508  X  2/100 

7,4 

ASSEMBLIES 

EXPERIMENTAL  DRAWINGS 

B3 

115 

97 

PRODUCTION  DRAWINGS 

B3 

115 

97 

PARTS  TO  BF  QUALIFIED 

29 

40 

34 

NEW  MATERIAL  AND 

2 

2 

2 

PROCESSES 

development  tests 

592 

838 

662 

ACCEPTANCE  TESTS 

13S0 

2100 

1500 

BAYS  OF  STE 

4 

4 

4 

development 

25. B 

41.6 

35  4 

assemblies 

PROTOTYPE  ASSEMBLIES 

25B 

416 

354 

SUBCONTRACT  SUPPORT,  mm 

21 

25 

25 

TOTAL  COMPONENTS 

264 

211  X  1.25 

635 

508  X  1.25 

515 

COMP.  IN  ANALOG  MODULES 

0 

0 

0 

ANALOG  MODULES/UNIT 

0 

0 

0 

COMP.  IN  DIGITAL  MODULES 

0 

0 

0 

DIGITAL  MODULES/UNIT 

0 

0 

0 

TYPES  OF  HYBRID  MODULES 

0 

0 

0 

SETS  OF  HYBRID  MODULES 

0 

0 

0 

breadboard  UNITS 

1 

1 

1 

development  units 

2 

2 

2 

PROTOTYPE  UNITS 

20 

20 

20 

SUBCONTRACT  DEVELOP 

500 

340 

360 

MENT  ODC,  K$ 

PURCHASED  PARTS  ODC,  K$ 

20S 

2B6 

317 

HOURLY  RATE,  $ 

lO.BO 

10  BO 

10.80 

MONTHS  TO  DEV.  PEAK 

15 

15 

15 

MONTHS  TO  ODC  PEAK 

12 

12 

12 

MONTHS  TO  END  OF 

30 

30 

30 

PROGRAM 

burden, percent 

13B 

13S 

138 

MISC.  ODC,  PERCENT 

2 

2 

2 

DRAWING  FACTOR 

144 

144 

144 

SUBSYSTEM  DESIGN 

20 

20 

20 

COMMfiNTS/RISK 


2  DP  +  2MP  +  1 
HARNESS  +  2 
8IU  +  7  CARDS 
55  X  2  = 

14  +  34  ICS 


370  X  2/100 


412  X  1.25 


155 


-■■  ..S4=iiia5k„-.»Jaa^4:iW'5r=E!=-:---  jt;  -.  *»-='=j~-'.«!r,-,-*5;.;Kxa^  'S.T  /  ■■  ’..■t,-:- 


Configuration  5  is  apparently  related  to  the  larger  number  of  electronic 
parts  in  that  design.  However,  since  the  larger  number  of  parts  is 
associated  with  the  second  processor  fof  identical  design)  it  would  seem 
that  the  development  labor  should  not  be  much  greater  than  in  Config¬ 
uration  1.  Manufacturing,  labor,  and  ODC  would  be  greater,  however. 
The  entries  in  the  table  indicate  that  development  labor  is  some  600 
thousand  dollars  greater  for  5  than  for  1.  This  does  seem  extreme 
even  though  more  testing  is  involved.  It  is  possible  that  more  refined 
input  would  cause  the  hardware  development  cost  for  Configuration  5 
to  come  more  in  line  with  the  other  configurations.  If  so,  one  must 
conclude  that  variations  in  total  program  costs  for  engineering  develop- 
m*Tit  of  thi.  six  designs  i*i  not  very  significant. 

9.5.2  Risk  Assessment 

None  of  the  designs  is  technically  infeasible  so  the  risk  factor  is 
primarily  with  respect  to  schedule.  A  30-month  schedule  was  assumed 
for  all  cases. 

Configuration  2  is  an  existing,  tested  design.  There  is  essentially 
no  risk  connected  with  this  system.  Where  development  risk  might 
come  in  is  if  one  desired  to  decrease  power  consumption  by  using  low 
power  Schottky  chips  to  the  greatest  extent  possible.  The  attempt  to 
hold  throughput  constant  while  reducing  power  consumption  poses  a 
design  problem  that  could  threaten  the  schedule.  The  risk  is  not 
believed  to  be  very  great. 

The  major  risk  in  Configuration  1  is  that  the  LSI  bipolar  micro¬ 
processor  chips  have  not  been  thoroughly  characterized.  If  the  chosen 
chips  do  not  live  up  to  their  promise,  a  schedule  delay  might  result 
because  of  the  necessity  for  finding  a  substitute  chip  set  or  for  design 
changes  to  accommodate  the  lesser  performance  of  the  chips.  A 
similar  conclusion  holds  for  Configuration  5  although  in  this  case 
throughput  is  not  quite  so  important.  Configurations  1,  2,  and  5  are 
all  considered  to  be  in  a  low  risk  category. 

There  are  two  risk  factors  associated  with  Configuration  3,  The 
first  is  the  design  of  the  LSI  chip  and  the  second  is  the  design  of  the 
memory  management  circuitry  which  is  a  new  design.  Since  an  LSI 
design  very  similar  to  what  is  required  already  exists,  the  risk  is  not 
thought  to  be  great.  Considering  the  two  risk  factors,  the  risk  for 
Configuration  3  is  judged  moderate. 

The  major  question  with  respect  to  risk  in  Configuration  4  has  to 
do  with  the  schedule  for  the  design  of  the  LSI  CPU.  This  is  a  new, 
rather  demanding  design.  The  probability  of  obtaining  a  successful 
design  in  much  less  than  2  years  is  rather  small.  Thus,  considering 
the  30-month  schedule,  the  risk  would  be  rather  high.  For  a  36-month 
schedule,  the  risk  would  be  no  greater  than  for  Configuration  3. 

The  hardware  risk  factors  for  Configuration  6  are  (1)  CPU  chips 
have  not  been  characterized,  therefore  not  proven;  (2)  memory  manage 
ment  circuitry  must  be  designed.  These  factors  are  not  of  too  much 


concern.  From  strictly  this  viewpoint,  the  risk  is  on  the  low  side  of 
moderate  (less  than  Configuration  3).  In  this  configuration,  however, 
there  is  some  question  of  suitability  for  the  DP  application. 

9.5.3  Software  Considerations 

The  two  comparisons  to  be  made  are  for  single  processors  versus 
distributed  processors  and  monoprocessors  versus  multiprocessors. 
The  factors  to  be  considered  are  software  development  and  software 
maintenance.  There  seems  to  be  little  or  no  hard  data  available  that 
pertains  to  the  situation,  v  For  example,  there  is  a  body  of  opinion  that 
producing  software  for  a  multiprocessor  is  more  difficult  than  for  a 
monoprocessor.  However,  no  controlled  experiments  have  been  made 
and  the  literature  does  not  seem  to  have  any  comparisons  of  the  two 
cases.  There  is  no  doubt  that  the  multiprocessor  does  introduce  new 
difficulties  into  software  design;  particularly  with  respect  to  shared 
resources.  While  the  guesses  as  to  the  increased  difficulty  have 
ranged  above  100  percent,  a  more  reasonable  guess  might  be  about 
30  percent  extra  difficulty  for  development. 

Central  Processor  Versus  Distributed  Processor 

If  there  is  a  convenient  functional  partitioning  for  the  total  set  of 
tasks,  the  software  development  effort  should  be  about  the  same  for 
both  configurations.  Where  a  difference  might  arise  is  with  a  task, 
not  easily  partitioned,  which  must  be  shared  between  two  processors. 
This  kind  of  situation  might  arise  when  a  new  task  is  added  to  the 
system  and  while  the  remaining  growth  capability  is  adequate,  it  is 
scattered  among  two  or  more  processors.  In  other  words,  it  is  more 
difficult  to  efficiently  use  the  growth  capacity  in  the  distributed  proces¬ 
sor  case.  Another  point  of  difference  has  to  do  with  maintenance. 

Any  change  which  affects  both  system  integration  functions  and  a  sub¬ 
system  function  will  require  a  memory  change  in  two  or  more  proces¬ 
sors  in  the  distributed  case  versus  one  in  the  central  case.  This 
would  be  true,  for  example,  if  the  autopilot  function  was  in  a  different 
processor  than  the  integration  function  and  a  change  were  made  to  the 
system  that  necessitated  an  autopilot  change. 


•'Available  data  about  commercial  large-scale  data  processing  systems 
are  not  felt  to  be  applicable  to  the  real-time  missile  processor  soft¬ 
ware  requirement. 
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